Wohin schreibt der SQLCommandBuilder seine Commands ?

[norbert44]

Guten Morgen zusammen,
ich benutze mit C# und Studio 2008 den

SqlCommandBuilder cmb = new SqlCommandBuilder(mydataadapter);
mydataadapter.Update(mydataset);

und gelöschte oder veränderte Daten werden in die SQL Server 2005 Datenbank geschrieben. Also alles O.K.

Beim debuggen ist mir aufgefallen, dass die
mydataadapter.UpdateCommand
mydataadapter.InsertCommand
mydataadapter.DeleteCommand alle leer sind. Trotzdem klappts.

Daher die Frage : Wohin schreibt der SQLCommandBuilder seine Commands?
Wie kann man sich diese Commands ( ausser mit cmb.getdeletecommand )
im Debugger anschauen.

Vielen Dank schon mal für die Antwort

Norbert

[Jürgen Thomas]

Hallo,

der DbCommandBuilder speichert die Befehle dorthin, wohin sie geschickt werden. Durch die GetXxxCommand-Methoden werden die Befehle erstellt; der Rückgabewert muss "irgendwo" gespeichert werden, wenn er verwendet werden soll. Dieses "irgendwo" ist in der Regel DbDataAdapter.XxxCommand.

Wie Du festgestellt hast, ist der Weg über DbCommandBuilder oft nicht nötig.

DbDataAdapter.UpdateCommand-Eigenschaft
Während der Ausführung von Update wird UpdateCommand automatisch generiert, wenn diese Eigenschaft nicht festgelegt wurde und Primärschlüsselinformationen im DataSet vorhanden sind.

Gruß Jürgen

[norbert44]

Hallo Jürgen, danke für die Antwort.

Ich habe es jetzt noch mal untersucht und die ( wahrscheinliche ) Erklärung gefunden.
Der Konstruktor des CommandBuilder:
SqlCommandBuilder cmb = new SqlCommandBuilder(mydataadapter);

BEWIRKT NICHT, dass im mydataadapter die Methoden XXXCommand eingetragen werden.
Die Eigenschaften bleiben leer, auch nach dem mydataadapter.Update(mydataset);

Also kann es nur so sein, dass der mydataadapter sich eine Referenz auf den CommandBuilder merkt und
ihn bei mydataadapter.Update(mydataset) "on the fly" die XXXCommands erzeugen laesst.

Ist zwar nicht schön ( wg. dem debuggen) , aber wenn man es weiss, ist es O.K.


Norbert