Hallo Allerseits,

ich habe den ganzen Tag versucht, mich mit ADO.Net auseinanderzusetzen.
Einiges klappt, vieles aber noch nicht.

Im nachfolgenden Beispiel möchte ich eine Tabelle "durchlaufen", um z.B.
einen bestimmten Feldwert zu überprüfen. Falls ein bestimmter Wert (z.B.
Null gefunden wird, soll der auf 0 gesetzt werden. ich weiss, daß man das
auch schneller und einfacher mit einem "UPDATE " machen könnte, aber ich
möchte lernen, wie ich einzelne Feldwerte lesen und ändern kann und diese
dann in der Tabelle aktualisieren kann.

Beispiel:
Dim l As Long

Dim da As New OleDb.OleDbDataAdapter

Dim ds As New DataSet

Dim dt As New DataTable

Dim dr As DataRow

Dim cb As OleDb.OleDbCommandBuilder

da.SelectCommand = New OleDb.OleDbCommand("SELECT * FROM tblFahrten", UpCNN)

cb = New OleDb.OleDbCommandBuilder(da)

ds.Clear()

da.Fill(ds, "tblFahrten")

For l = 0 To ds.Tables(0).Rows.Count - 1

dr = ds.Tables(0).Rows(l)

If IsDBNull(dr!FASchichtIdx) = True Then

dr.BeginEdit()

dr!FASchichtIdx = 0

dr.EndEdit()

Try

da.Update(ds, "tblFahrten")

Catch ex As Exception

MsgBox(ex.Message, MsgBoxStyle.Information + MsgBoxStyle.OkOnly)

End Try

End If

Next

Die Zeile: da.Update(ds, "tblFahrten") macht Probleme

Es kommt die Rückmeldung: Abfrage zu komplex.

Wenn ich es richtig verstehe, sollte der da.Update die gesamte Tabelle
aktualisieren.

Für mich stellt sich die Frage: Warum geht das nicht??

Wie kann ich nur die eine Zeile aktualisieren?

Vielen Dank für jede Hilfe

Christoph

"Christoph Schmitt" <jeep10*abacho.de> schrieb im Newsbeitrag
news:hcn004$q35$1*online.de...
> Hallo Peter,
>
> ich verstehe einige (grundlegende) Dinge nicht. Wahrscheinlich, weil ich
> noch zu sehr in der DAO oder ADO Datenzugriffs Technologie verwurzelt bin.
>
> Die Rows sind Bestandteil des Datasets. In meinem Beispielcode ändere ich
> einzelne Feldwerte.
>
> Der Dataadapter weiss von diesen Änderungen und soll sie auf "Befehl" in
> die Datenbank übertragen.
>
> Warum funktioniert:
>
> da.Update(ds, "tblFahrten")
>
> dann nicht?

Hi Christoph,
wie ermittelst du, dass das nicht funktioniert? Was sagt der Rückkehrcode
(Anzahl der aktualisierten Datensätze)?

Trace.WriteLine(String.Format("{0} Datensätze wurden aktualisiert",
da.Update(ds, "tblFahrten"))

--
Viele Gruesse

Peter

Hallo Peter,

wo/wie sehe ich den Rückgabewert der Trace-Funktion?

Ich ermittele momentan "einfach" in meiner Datenbank. Dort kommen die
geänderten Daten nicht an.

In meinem Frust, daß ich es nicht hinbekomme, habe ich dann nochmal mit dem
Commandbuilder experimentiert.

Der Rückgabewert des .GetUpdateCommand liefert mir sehr merkwürdige Dinge.

Alle Feldwerte sind dort in dem SQL-String immer mit einem ? versehen

Also z.B. SELECT FAIndex = ? , FASchichtIdx = ?, ......

Da scheint doch irgendwas nicht richtig zu funktionieren.

Die Access-Tabelle hat eine Spalte FAIndex, die als Primärschlüssel angelegt
ist.

Ich habe mich jetzt stundenlang mit diesem Tham beschäftigt, unzählihe
MS-Seiten durchgearbeitet, Beispiele aus diversen Büchern nachgearbeitet,
leider ohne Erfolg.

Wo liegt mein Denk-/Verständnisproblem??

Vielen Dank für weitere Unterstützung.

Christoph

"Peter Fleischer" <peter.fleischer_nospam_*gmx.de> schrieb im Newsbeitrag
news:%23Z$qj6$WKHA.5368*TK2MSFTNGP02.phx.gbl...
> "Christoph Schmitt" <jeep10*abacho.de> schrieb im Newsbeitrag
> news:hcn004$q35$1*online.de...
>> Hallo Peter,
>>
>> ich verstehe einige (grundlegende) Dinge nicht. Wahrscheinlich, weil ich
>> noch zu sehr in der DAO oder ADO Datenzugriffs Technologie verwurzelt
>> bin.
>>
>> Die Rows sind Bestandteil des Datasets. In meinem Beispielcode ändere ich
>> einzelne Feldwerte.
>>
>> Der Dataadapter weiss von diesen Änderungen und soll sie auf "Befehl" in
>> die Datenbank übertragen.
>>
>> Warum funktioniert:
>>
>> da.Update(ds, "tblFahrten")
>>
>> dann nicht?
>
> Hi Christoph,
> wie ermittelst du, dass das nicht funktioniert? Was sagt der Rückkehrcode
> (Anzahl der aktualisierten Datensätze)?
>
> Trace.WriteLine(String.Format("{0} Datensätze wurden aktualisiert",
> da.Update(ds, "tblFahrten"))
>
> --
> Viele Gruesse
>
> Peter

"Christoph Schmitt" <jeep10*abacho.de> schrieb im Newsbeitrag
news:hcp3gl$i17$1*online.de...
> ...
> wo/wie sehe ich den Rückgabewert der Trace-Funktion?

Hi Christoph,
das Ergebnis der Trace-Nutzung wird über den im Programm aktivierten
TraceListener ausgegeben. Wenn da nichts vorgesehen ist, kommen die
Nachrichten im Immediate Window in der IDE an.

> Ich ermittele momentan "einfach" in meiner Datenbank. Dort kommen die
> geänderten Daten nicht an.

Ist das auch die Datenbank, in der das Programm ändert? Ein beliebter Fehler
ist, die Datenbankdatei im Projektordner zu halten und mit "always copy" zu
versehen. Das Programm nutzt dann die Kopie im bin-Ordner. Im Original im
Projektordner wird natürlich nichts verändert.

> In meinem Frust, daß ich es nicht hinbekomme, habe ich dann nochmal mit
> dem Commandbuilder experimentiert.
>
> Der Rückgabewert des .GetUpdateCommand liefert mir sehr merkwürdige Dinge.
>
> Alle Feldwerte sind dort in dem SQL-String immer mit einem ? versehen
>
> Also z.B. SELECT FAIndex = ? , FASchichtIdx = ?, ......

Da fehlen dir scheinbar elementare Kenntnisse zu SQL? das Fragezeichen ist
für die Jet der Platzhalter für Werte, die die Parameter-Objekte
bereitstellen.

> Da scheint doch irgendwas nicht richtig zu funktionieren.

Und was?

> Die Access-Tabelle hat eine Spalte FAIndex, die als Primärschlüssel
> angelegt ist.

Ohne diese Spalte könnte der Commandbuilder auch nicht den Mechanismus für
die Identifikation der Datensätze aufbauen.

> Ich habe mich jetzt stundenlang mit diesem Tham beschäftigt, unzählihe
> MS-Seiten durchgearbeitet, Beispiele aus diversen Büchern nachgearbeitet,
> leider ohne Erfolg.
>
> Wo liegt mein Denk-/Verständnisproblem??

Dein Denk-/Verständnisproblem liegt vermutlich darin, dass du erwartest, in
ein paar Stunden etwas zu verstehen, wofür andere sehr vile mehr Zeit
benötigen. ich habe zu VB6-Zeiten auch einige Monate benötigt, um ADO im
wesentlichen zu verstehen. ADO.NET kann aber noch mehr als das klassische
ADO.


--
Viele Gruesse

Peter

Hallo Peter,

Du hast wahrscheinlich Recht, daß ich zu schnell verstehen möchte.

Ich geb aber nicht auf.

habe nun folgenden Zustand herausgearbeitet:

Übergebe ich in meinem SELECT String dezidierte Feldnamen (inklusiv und vor
allem die Spalte mit dem Primärindex) und führe dann meine Prozedur aus...
funktioniert sie!

Ändere ich den SELECT wieder in SELECT * FROM mTabelle geht wieder nichts
beim Update

Offensichtlich kiegt hier mein Problem.

Hilft das vielleicht als Info, um mir einen Tip für mein weiteres Vorgehen
zu geben?

Viele Grüße (und vielen Dank für Eure Aufmerksamkeit)
Christoph

"Peter Fleischer" <peter.fleischer_nospam_*gmx.de> schrieb im Newsbeitrag
news:e2HiseLXKHA.1792*TK2MSFTNGP04.phx.gbl...
> "Christoph Schmitt" <jeep10*abacho.de> schrieb im Newsbeitrag
> news:hcp3gl$i17$1*online.de...
>> ...
>> wo/wie sehe ich den Rückgabewert der Trace-Funktion?
>
> Hi Christoph,
> das Ergebnis der Trace-Nutzung wird über den im Programm aktivierten
> TraceListener ausgegeben. Wenn da nichts vorgesehen ist, kommen die
> Nachrichten im Immediate Window in der IDE an.
>
>> Ich ermittele momentan "einfach" in meiner Datenbank. Dort kommen die
>> geänderten Daten nicht an.
>
> Ist das auch die Datenbank, in der das Programm ändert? Ein beliebter
> Fehler ist, die Datenbankdatei im Projektordner zu halten und mit "always
> copy" zu versehen. Das Programm nutzt dann die Kopie im bin-Ordner. Im
> Original im Projektordner wird natürlich nichts verändert.
>
>> In meinem Frust, daß ich es nicht hinbekomme, habe ich dann nochmal mit
>> dem Commandbuilder experimentiert.
>>
>> Der Rückgabewert des .GetUpdateCommand liefert mir sehr merkwürdige
>> Dinge.
>>
>> Alle Feldwerte sind dort in dem SQL-String immer mit einem ? versehen
>>
>> Also z.B. SELECT FAIndex = ? , FASchichtIdx = ?, ......
>
> Da fehlen dir scheinbar elementare Kenntnisse zu SQL? das Fragezeichen ist
> für die Jet der Platzhalter für Werte, die die Parameter-Objekte
> bereitstellen.
>
>> Da scheint doch irgendwas nicht richtig zu funktionieren.
>
> Und was?
>
>> Die Access-Tabelle hat eine Spalte FAIndex, die als Primärschlüssel
>> angelegt ist.
>
> Ohne diese Spalte könnte der Commandbuilder auch nicht den Mechanismus für
> die Identifikation der Datensätze aufbauen.
>
>> Ich habe mich jetzt stundenlang mit diesem Tham beschäftigt, unzählihe
>> MS-Seiten durchgearbeitet, Beispiele aus diversen Büchern nachgearbeitet,
>> leider ohne Erfolg.
>>
>> Wo liegt mein Denk-/Verständnisproblem??
>
> Dein Denk-/Verständnisproblem liegt vermutlich darin, dass du erwartest,
> in ein paar Stunden etwas zu verstehen, wofür andere sehr vile mehr Zeit
> benötigen. ich habe zu VB6-Zeiten auch einige Monate benötigt, um ADO im
> wesentlichen zu verstehen. ADO.NET kann aber noch mehr als das klassische
> ADO.
>
>
> --
> Viele Gruesse
>
> Peter

Hallo Peter,

jetzt habe ich noch etwas rausgefunden.

Die tblFahrten enthält ca. 60 Felder. Das Update schlägt fehl, wenn ich die
Daten mit SELECT * FROM tblFahrten abrufe (und geändert) wieder
zurückschreiben will.
Nehme ich mal eine andere Tabelle, mit lediglich 10 Feldern und rufe die
Daten ebenfalls mit SELECT * FROM Tabelle2 auf, kann ich Sie problemlos
ändern und in die Datenbank zurückschreiben.
Gruß
Christoph


"Peter Fleischer" <peter.fleischer_nospam_*gmx.de> schrieb im Newsbeitrag
news:e2HiseLXKHA.1792*TK2MSFTNGP04.phx.gbl...
> "Christoph Schmitt" <jeep10*abacho.de> schrieb im Newsbeitrag
> news:hcp3gl$i17$1*online.de...
>> ...
>> wo/wie sehe ich den Rückgabewert der Trace-Funktion?
>
> Hi Christoph,
> das Ergebnis der Trace-Nutzung wird über den im Programm aktivierten
> TraceListener ausgegeben. Wenn da nichts vorgesehen ist, kommen die
> Nachrichten im Immediate Window in der IDE an.
>
>> Ich ermittele momentan "einfach" in meiner Datenbank. Dort kommen die
>> geänderten Daten nicht an.
>
> Ist das auch die Datenbank, in der das Programm ändert? Ein beliebter
> Fehler ist, die Datenbankdatei im Projektordner zu halten und mit "always
> copy" zu versehen. Das Programm nutzt dann die Kopie im bin-Ordner. Im
> Original im Projektordner wird natürlich nichts verändert.
>
>> In meinem Frust, daß ich es nicht hinbekomme, habe ich dann nochmal mit
>> dem Commandbuilder experimentiert.
>>
>> Der Rückgabewert des .GetUpdateCommand liefert mir sehr merkwürdige
>> Dinge.
>>
>> Alle Feldwerte sind dort in dem SQL-String immer mit einem ? versehen
>>
>> Also z.B. SELECT FAIndex = ? , FASchichtIdx = ?, ......
>
> Da fehlen dir scheinbar elementare Kenntnisse zu SQL? das Fragezeichen ist
> für die Jet der Platzhalter für Werte, die die Parameter-Objekte
> bereitstellen.
>
>> Da scheint doch irgendwas nicht richtig zu funktionieren.
>
> Und was?
>
>> Die Access-Tabelle hat eine Spalte FAIndex, die als Primärschlüssel
>> angelegt ist.
>
> Ohne diese Spalte könnte der Commandbuilder auch nicht den Mechanismus für
> die Identifikation der Datensätze aufbauen.
>
>> Ich habe mich jetzt stundenlang mit diesem Tham beschäftigt, unzählihe
>> MS-Seiten durchgearbeitet, Beispiele aus diversen Büchern nachgearbeitet,
>> leider ohne Erfolg.
>>
>> Wo liegt mein Denk-/Verständnisproblem??
>
> Dein Denk-/Verständnisproblem liegt vermutlich darin, dass du erwartest,
> in ein paar Stunden etwas zu verstehen, wofür andere sehr vile mehr Zeit
> benötigen. ich habe zu VB6-Zeiten auch einige Monate benötigt, um ADO im
> wesentlichen zu verstehen. ADO.NET kann aber noch mehr als das klassische
> ADO.
>
>
> --
> Viele Gruesse
>
> Peter

"Christoph Schmitt" <jeep10*abacho.de> schrieb im Newsbeitrag
news:hcq6b0$hej$1*online.de...
> ...
> Die tblFahrten enthält ca. 60 Felder. Das Update schlägt fehl, wenn ich
> die Daten mit SELECT * FROM tblFahrten abrufe (und geändert) wieder
> zurückschreiben will.
> Nehme ich mal eine andere Tabelle, mit lediglich 10 Feldern und rufe die
> Daten ebenfalls mit SELECT * FROM Tabelle2 auf, kann ich Sie problemlos
> ändern und in die Datenbank zurückschreiben.

Hi Christoph,
da wäre als erster Schritt eine Normalisierung der Datenbank angebracht. Die
Jet hat Grenzen bezüglich der Länge der SQL-Anweisung.

--
Viele Gruesse

Peter

Hi Peter,

ok. Danke für Deine Unterstützung!
Viele Grüße
Christoph

"Peter Fleischer" <peter.fleischer_nospam_*gmx.de> schrieb im Newsbeitrag
news:ep3GCgQXKHA.3404*TK2MSFTNGP05.phx.gbl...
>
> "Christoph Schmitt" <jeep10*abacho.de> schrieb im Newsbeitrag
> news:hcq6b0$hej$1*online.de...
>> ...
>> Die tblFahrten enthält ca. 60 Felder. Das Update schlägt fehl, wenn ich
>> die Daten mit SELECT * FROM tblFahrten abrufe (und geändert) wieder
>> zurückschreiben will.
>> Nehme ich mal eine andere Tabelle, mit lediglich 10 Feldern und rufe die
>> Daten ebenfalls mit SELECT * FROM Tabelle2 auf, kann ich Sie problemlos
>> ändern und in die Datenbank zurückschreiben.
>
> Hi Christoph,
> da wäre als erster Schritt eine Normalisierung der Datenbank angebracht.
> Die Jet hat Grenzen bezüglich der Länge der SQL-Anweisung.
>
> --
> Viele Gruesse
>
> Peter

Hi Peter,

ok. Danke für Deine Unterstützung!
Viele Grüße
Christoph

"Peter Fleischer" <peter.fleischer_nospam_*gmx.de> schrieb im Newsbeitrag
news:ep3GCgQXKHA.3404*TK2MSFTNGP05.phx.gbl...
>
> "Christoph Schmitt" <jeep10*abacho.de> schrieb im Newsbeitrag
> news:hcq6b0$hej$1*online.de...
>> ...
>> Die tblFahrten enthält ca. 60 Felder. Das Update schlägt fehl, wenn ich
>> die Daten mit SELECT * FROM tblFahrten abrufe (und geändert) wieder
>> zurückschreiben will.
>> Nehme ich mal eine andere Tabelle, mit lediglich 10 Feldern und rufe die
>> Daten ebenfalls mit SELECT * FROM Tabelle2 auf, kann ich Sie problemlos
>> ändern und in die Datenbank zurückschreiben.
>
> Hi Christoph,
> da wäre als erster Schritt eine Normalisierung der Datenbank angebracht.
> Die Jet hat Grenzen bezüglich der Länge der SQL-Anweisung.
>
> --
> Viele Gruesse
>
> Peter

Hallo Christoph,

> ich verstehe einige (grundlegende) Dinge nicht. Wahrscheinlich, weil ich
> noch zu sehr in der DAO oder ADO Datenzugriffs Technologie verwurzelt bin.

.... vor allem wohl in der DAO Technologie.
ADO und ADO.net dagegen sind gar nicht so sehr weit
auseinander.


> Die Rows sind Bestandteil des Datasets.

Nein.
Ein DataSet ist ein Container für DataTables und evtl.
Realtion-Objekte, mit denen DataTables zueinander
in Beziehung gesetzt werden können.

Rows findest Du in einer DataTable. Eine solche
DataTable kannst Du im weitesten Sinne mit einem
ADODB.Recordset vergleichen. Die Datensätze im
ADODB.Recordset finden dann ihre Entsprechung
in den Rows der DataTable.

Im Gegensatz zu einem ADODB.Recordset gibt es
in einer DataTable keinen aktuellen Datensatz bzw.
keinen Datensatzzeiger. Diese Funktionalität wird
bei .net durch den sog. CurrencyManager bereitgestellt.

Zum Versändnis der drei grundlegenden Objekte
DataTable, DataView und CurrencyManager solltest Du
Dir mal die Beispiele unter

www.gssg.de -> Visual Basic -> VB.net
in den Rubriken
-> Datenbank
-> DataGridView
-> DataTable / DataView / CurrencyManager

Das Zusammenspiel von DataTable, DataView und
CurrencyManager erleichtert Dir auch das Verständnis
des DataBinding-Objektes, welches eben diese drei
Objekte kapselt.



> In meinem Beispielcode ändere ich einzelne Feldwerte.
>
> Der Dataadapter weiss von diesen Änderungen und soll sie auf "Befehl" in
> die Datenbank übertragen.
>
> Warum funktioniert:
>
> da.Update(ds, "tblFahrten")
>
> dann nicht?

Dafür gibt es mehrere Gründe.

Der DataAdapter prüft beim .Update die RowStates der
einzelnen Rows der zugehörigen DataTable. Hat eine
DataRow den RowState Added, Modified oder Deleteted,
weiss der DataAdapter, dass er die entsprechende Änderung
in der zugehörigen DB-Tabelle vornehmen muss.

Mit einem DataRow.AcceceptChanges wird der RowState der betr.
DataRow auf DataRow.Unchanged gesetzt.
Mit einem DataTable.AcceptChanges werden die RowStates aller
DataRows dieser DataTable auf .Unchanged gesetzt.

DataRows mit dem RowState = Unchanged bedeuten für den
DataAdapter, dass er für diese DataRows in der DB-Tabelle
nichts speichern oder löschen muss.

Hast Du also vor dem DataAdapter.Update in Deinem Code
z.B. DataTable.AcceptChanges ausgeführt, dann gibt es für
den DataAdapter nichts mehr zu tun, ein DataAdapter.Update
bleibt ohne Auswirkung.

Um einen Datensatz in der zugehörigen DB-Tabelle ändern oder
löschen zu können, braucht der DataAdapter einen gültigen
Update- bzw. Delete- Command dessen Where-Klausel den zu
bearbeitenden Datensatz eindeutig identifiziert. Die Where-Klausel
muss sich also auf ein Feld oder eine Kombination von Feldern
beziehen, die eindeutige Werte oder Wertekombinationen
enthalten. Im einfachsten Fall sollte die Where-Klausel sich
auf ein Primärschlüsselfeld beziehen.
Deine Update- und Delete- Commands sollten also eine
Where-Klausel enthalten, die eindeutig einen ganz bestimmten
Datensatz oder eben eine Gruppe von Datensätzen identifiziert.
Ist dies nicht der Fall, weiss der DataAdapter nicht, was er
ändern oder löschen soll.


> Irgendwie fällt bei mir der Groschen nicht.

Kommt schon noch. ;-)
Aber Du solltest Dich unbedingt erst mal mit den wirklich
grundlegenden Dingen, wie eben DataTable, DataView und
CurrencyManager, sowie deren Zusammenspiel vertraut
machen.
Im nächsten Schritt wären dann DataSet mit DataTables und
DataRelation-Objekten an der Reihe.
Das sind alles noch Objekte, die vollkommen DB-unspezifisch
sind und auch ohne irgendeinen DB-Hintergrund existieren und
arbeiten können.
Beispiele zu diesen Objekten findest Du reichlich unter

www.gssg.de -> Visual Basic -> VB.net

Als nächsten Schritt würde ich Dir das Beispiel unter

www.gssg.de -> Visual Basic -> VB.net
-> DB CommandObjekte / DataReader

empfehlen. Darin siehst Du, wie Command-Objekte ganz
ohne DataAdapter, der letztlich auch nur solche Command-
Objekte kapselt, funktionieren.


Gruß aus St.Georgen
Peter Götz
www.gssg.de (mit VB-Tipps u. Beispielprogrammen)