expertenaustausch > microsoft.* > microsoft.vb.datenbank

Herbert Leichtfuss (28.08.2004, 15:23)
Hallo,

ich habe folgendes Problem und ich würde mich freuen, wenn jemand eine
Idee/Lösungsmöglichkeit postet. Ich benutze den Data Environment-Designer
mit hierarchischen Recordsets.

Auf ein Recordset der ersten Stufe kann ich erfolgreich zugreifen:
DE.rsRecset.[...]. Wie kann ich auf ein untergeordnetes Recordset - erzeugt
durch eine Abfrage im Data Environmet Designer und mit 1.Recordset
verknüpft - zugreifen ?
DE.Recset1.Recset2.[...] gibt es nicht. Ich kann also z.B. keinen Datensatz
in einem untergeordneten Recordset (ohne datengeb. Steuerelemente)
bearbeiten oder löschen ?

Ist das bei Design so, oder mache ich was (konzeptionelles) falsch ?

Über einen Tipp würde ich mich sehr freuen,

Hotze

PS.:
Nur für diejenigen, die gerne Details zum Problem wüssten, hier die Details:

In dem Teilproblem sind 2 Tabellen involviert. Die Tabelle adressen enthält
Adressen und die Tabelle vorgaenge enthält Aufträge/Vorgänge. Diese beiden
Tabellen stehen in 1:n Relation (n Aufträge -> 1 Kunde).

In einem Formular zur Auftrags-/Vorgangsverwaltung habe ich zum einen ein
DataGrid mit einem Recordset (DE.rsVorg) im DataEnvironmet-Designer (DE)

SELECT vorgaenge.*, adressen.NN, adressenVN
FROM adressen, vorgaenge
WHERE adressen.ID=vorgaenge.kunde;

verbunden, um komfortabel nach Aufträgen suchen zu können. In diesem
Recordset sind alle für die Suche relevanten Daten enthalten (Vorgangsdatum,
Kundenname..); das Recordset enthält Daten von beiden Tabellen. Ich möchte
ja auch nach Vorgängen bestimmter Kunden suchen/filtern können und auch
zusammenhängend bearbeiten (drucken, Statistik..) können. Per
Change-Ereignis des Suchfeldes grenze ich das Recordset, welches im DataGrid
dargestellt wird, mit der Filter-Methode entsprechend ein. Das klappt soweit
wunderbar und ich muss nicht ständig ein Query machen und die Steuerelemente
neu anbinden. Das Problem ist folgendes:

Wenn ich einen Vorgang in diesem Recordset löschen möchte (DE.rsVorg.Delete)
geht das nicht: 'Nicht genügend Schlüsselfeldinformationen zum
Aktualisieren'. Das ist wahrscheinlich dadurch begründet, weil das Recordset
Daten von beiden Tabellen in der Form enthält, als dass eine Mehrfachauswahl
der Adressen passiert und die DB-Engine nicht weiss, was sie mit der
rsVorg.Delete-Methode anfangen soll oder es ist durch die referentielle
Integrität begründet. Jedenfalls möchte ich in diesem Moment natürlich nur
den Datensatz in der Tabelle vorgaenge löschen und keinesfalls die
Kundendaten in der Tabelle adressen.

Die naheliegenste Lösung für mich war also, eine untergeordnete Abfrage
(Recordset) zu formulieren, welche alle Daten aus der zu verändernden
Tabelle (hier vorgaenge) enthält

SELECT * FROM vorgaenge;

... und ich dann im Designer mit rsVorg per Primärschlüssel
verbinde/verknüpfe.

Diese Detaildaten werden mir zwar in allen Datengebundenen Steuerelemente
(Textfelder) angezeigt, jedoch kann ich nicht per Code darauf zugreifen:

Wo ich noch in der 1. Hierarchiestufe in der Art 'DE.rsVorg.Delete' darauf
zugreifen konnte, geht das nun nicht mehr, weil sich der Detaildatensatz nun
auf der 2. Stufe befindet.

Gibt es für das Verhalten vom Designer hierfür eine logische Erklärung ?

Auch möchte ich gerne wissen, was denn bei dem DE.rsVorg.Delete (siehe
Abfrage oben) genau passiert; ggf muss ich nur die Abfrage umformulieren.
Also das z.B. bei einer Aggregation (Gruppierung o.ä.) eine Aktualisierung
nicht funktioniert, kann sogar ich mir denken.
Peter Fleischer (28.08.2004, 16:25)
Herbert,
dein Posting zeigt wiederholt, dass die Nutzung des DataEnviroments bei vom
Standard abweichenden Bedingungen zu Verständnisproblemen führen kann. Ich
empfehle dir deshalb dringend, darauf zu verzichten un die paar Codezeilen
selbst zu schreiben. Das fördert das Verstehen des ADO-Objektmodells.

Dein Problem könnte so gelöst werden (ohne DataEnvironment mit Access):

Dim cn As New ADODB.Connection
Dim rs1 As New ADODB.Recordset
Dim rs2 As New ADODB.Recordset

cn.ConnectionString = "Provider=MSDataShape;" & _
"Data Source=" & "c:\temp\test.mdb;& _
"Data Provider=MICROSOFT.JET.OLEDB.4.0"
cn.Open

strSQL = "SHAPE {SELECT * FROM adressen}" & _
" APPEND ({SELECT * FROM vorgaenge} AS Cmd2" & _
" RELATE ID TO kunde)"

rs1.Cursorlocation = adUseClient
rs1.Open strSQL, cn, adOpenStatic, adLockOptimistic
Set DataGrid1.DataSource = rs1
Set rs2 = rs1("Cmd2").Value
Set DataGrid2.DataSource = rs2

Und im rs2 kann man Detail-Datensätze löschen.

Peter
Herbert Leichtfuss (28.08.2004, 17:15)
Hallo Peter,

vielen Dank zunächst für die Antwort. Ich hatte das Projekt auch mit

ADO-Code begonnen, mich aber mittendrin umentschieden.

Es ist bestimmt so, dass ich das ADO-Konzept nicht ausreichend überblicke,

zumal ich erst seit kurzem mit VB und ADO beschäftige. Für einen Wechsel

zur Code-Variante nur des Lerneffektes wegen pressiert die Sache

mittlerweile zu sehr.

Grüße

"Peter Fleischer" <peter.fleischer_nospam_> schrieb im Newsbeitrag
news:7tu1
[..]
Peter Fleischer (28.08.2004, 17:32)
Herbert Leichtfuss wrote:
....
> zumal ich erst seit kurzem mit VB und ADO beschäftige. Für einen
> Wechsel
> zur Code-Variante nur des Lerneffektes wegen pressiert die Sache
> mittlerweile zu sehr.


Herbert,
und wie willst du, ohne das ADO-Objektmodell zu verstehen, es anwenden?

Peter
Herbert Leichtfuss (29.08.2004, 01:23)
Danke, Peter,

ich galub', ich habs geschnallt. Nix anderes macht der Designer nämlich auch
nicht. Ich werde den Designer weiter verwenden.

Grüsse,

Herb

"Peter Fleischer" <peter.fleischer_nospam_> schrieb im Newsbeitrag
news:7tu1
[..]
Peter Fleischer (29.08.2004, 09:39)
Herbert Leichtfuss wrote:
...
> ich galub', ich habs geschnallt. Nix anderes macht der Designer
> nämlich auch nicht. Ich werde den Designer weiter verwenden.


Herbert,
der Designer arbeit auch nur mit dem ADO-Objektmodell. Er führt nur eine
Reihe von Aktivitäten selbständig aus. Solange du bei Standardabläufen
bleibst, mag das kein Problem sein. Wenn du aber etwas anspruchvoller
arbeiten willst, wie beispielsweise andere Zugriffwege bei der Anwendung,
wirst du wegen der implizit durchgeführten Aktivitäten noch genügend Stress
erleben. Per Code behälst du den Überblick und der Aufwand reduziert sich
langfristig trotz scheinbar einfacher Handhabung des Designers.

Peter
Ähnliche Themen