benutzerdefinierte Updates

[daribla]

Ich habe ein typisiertes Dataset mit den automatisch generierten Update, Insert und Delete Commands.

Wie erstelle ich mein eigenes Updatecommand für den Tableadapter, der an meine Form gebunden ist?

Wird durch mein neues Updatecommand das generierte Überschrieben?

Macht diese Methode einen Unterschied zu der Methode, bei der ich mir ein eigenes Mysql -Updatecommand erstelle und mit ExecuteNonQuery ausführe?

Wie Update ich Datensätze, die durch ein Join erstellt worden sind?

[Jürgen Thomas]

Hallo,

ich kenne typisierte DataSets und nutze sie, aber ohne den Überbau des TableAdapters.

Wie erstelle ich mein eigenes Updatecommand für den Tableadapter, der an meine Form gebunden ist?

Eine Möglichkeit ist der CommandStringBuilder.

Wird durch mein neues Updatecommand das generierte Überschrieben?

Das gehört zu den Dingen, die ich nicht weiß. Ich meine aber gelesen zu haben, dass für einen TableAdapter mehrere SELECTs vorgemerkt werden können; dazu kann es dann auch passende Speichern-Befehle geben.

Macht diese Methode einen Unterschied zu der Methode, bei der ich mir ein eigenes Mysql -Updatecommand erstelle und mit ExecuteNonQuery ausführe?

Naja, bei einem eigenen SQL-Befehl hast du die volle Kontrolle, während der TableAdapter sich irgendetwas ausdenkt, was er für unter Umständen sinnvoll hält. Beispielsweise "weißt du", dass das aktuelle Datum automatisch (z.B. durch einen Trigger) gespeichert wird, aber der TableAdapter will irgendeinen eigenen Wert eintragen (z.B. den von der vorigen Speicherung).

Wie Update ich Datensätze, die durch ein Join erstellt worden sind?

Grundsätzlich nicht! Das geht nur durch manuell erzeugte SQL-Befehle.

Der TableAdapter und überhaupt der CommandStringBuilder können nur in Funktion treten, wenn sich die Spalten auf genau eine Tabelle beziehen und dabei der PK (PrimaryKey) in den Spalten enthalten ist. Hintergrund dafür ist, dass sich das Speichern auf genau eine Tabelle beziehen muss.

Gruß Jürgen

[Ralf Jansen]

Wie erstelle ich mein eigenes Updatecommand für den Tableadapter, der an meine Form gebunden ist?

Wird durch mein neues Updatecommand das generierte Überschrieben?

Im Dataset Designer auf den Tableadapter klicken und in den Properties findest du dann InsertCommand, DeleteCommand und UpdateCommand. Da kannst du dann den jeweiligen CommandText ändern. Für einen weitere Select einfach im Contextmenu des Tableadapters die 'Add/Query'- Funktion (bzw. das deutsche Äquivalent) aufrufen.

Ein Tableadapter kann beliebig viele Queries haben aber nur jeweils einen Insert,Update,Delete. Mir fällt auch kein Grund ein mehrere haben zu müssen. Hast du mal ein Beispiel wofür du das braucht?

Wie Update ich Datensätze, die durch ein Join erstellt worden sind?

Eine Stored Procedure nutzen die die Daten auf die verschiedenen Tabellen verteilt. Oder einfach in das UpdateCommand 2 oder mehr Update Befehle reinschreiben. Dass geht aber nur wenn dein DB Treiber einen AufrufBatch erlaubt und dir der Return Wert(Records Affected) der Updates egal ist. Denn du bekommst nur vom letzten Update einen auswertbaren Return. Oder deine Datenbanken unterstützt update bare Views. Dann würde ich deinen Join einfach als View in der Datenbank ablegen. Keine Ahnung ob MySQL sowas kann.

[daribla]

Ich meinte eigentlich, wie ich per Programmcode das Updatecommand des Tableadapters erstelle (ändere), welches ich dann mit tableadapter.update aufrufe und inwieweit sich diese Vorgehensweise gegenüber der Methode unterscheidet, bei der ich ein Updatecommand erstelle und mit ExecuteNonQuery aufrufe.

[Jürgen Thomas]

Ich meinte eigentlich, wie ich per Programmcode das Updatecommand des Tableadapters erstelle (ändere), welches ich dann mit tableadapter.update aufrufe

Ich weiß es nicht, weil ich (wie gesagt) nicht damit arbeite. Schau doch einmal in die Designer.cs, wo und wie die Befehle dort genannt sind, und baue dies "irgendwo" nach. (Ich weiß, dass dieses Datenmonster sehr unübersichtlich ist...)

und inwieweit sich diese Vorgehensweise gegenüber der Methode unterscheidet, bei der ich ein Updatecommand erstelle und mit ExecuteNonQuery aufrufe.

Wenn alle drei Befehle - INSERT, UPDATE, DELETE - vorbereitet sind, können mit einem einzigen Befehl DbDataAdapter.Update alle Änderungen "am Stück" gespeichert werden, und die DataTable prüft anhand des DataRowState selbst, welche Datensätze geändert werden müssen.

Bei ExecuteNonQuery musst du das manuell steuern (jede Zeile einzeln prüfen, Befehl auswählen, Parameter zuordnen, Befehl ausführen; dazu wegen der Geschwindigkeit alles in eine Transaction kapseln). All das wird dir abgenommen.

Gruß Jürgen

[Ralf Jansen]

Ich meinte eigentlich, wie ich per Programmcode das Updatecommand des Tableadapters erstelle (ändere), welches ich dann mit tableadapter.update aufrufe und inwieweit sich diese Vorgehensweise gegenüber der Methode unterscheidet, bei der ich ein Updatecommand erstelle und mit ExecuteNonQuery aufrufe.

Da kann ich nur Gegenfragen 'warum sollte man das wollen' Das hört sich so an als wolltest du 'gegen' den Tableadapter programmieren und nicht 'mit' dem Tableadapter.

Ansonsten sind die Insert-, Update-, Delete- Command Properties normale DBCommand Objekte des jeweiligen Typs mit dem der Tableadapter generiert wurde. Die kann man wahrscheinlich einfach im Code erzeugen und den 3 entsprechenden Properties zuweisen.

[Jürgen Thomas]

... normale DBCommand Objekte des jeweiligen Typs mit dem der Tableadapter generiert wurde. Die kann man wahrscheinlich einfach im Code erzeugen und den 3 entsprechenden Properties zuweisen.

So ist es (nicht nur wahrscheinlich, sondern wirklich). Die Frage ist lediglich, wie genau sie in dem Datenmonster TableAdapter bezeichnet sind; und für jede DataTable gibt es eigene. Jürgen

[daribla]

Ich weiß es nicht, weil ich (wie gesagt) nicht damit arbeite. Schau doch einmal in die Designer.cs, wo und wie die Befehle dort genannt sind, und baue dies "irgendwo" nach. (Ich weiß, dass dieses Datenmonster sehr unübersichtlich ist...)

Wenn alle drei Befehle - INSERT, UPDATE, DELETE - vorbereitet sind, können mit einem einzigen Befehl DbDataAdapter.Update alle Änderungen "am Stück" gespeichert werden, und die DataTable prüft anhand des DataRowState selbst, welche Datensätze geändert werden müssen.

Bei ExecuteNonQuery musst du das manuell steuern (jede Zeile einzeln prüfen, Befehl auswählen, Parameter zuordnen, Befehl ausführen; dazu wegen der Geschwindigkeit alles in eine Transaction kapseln). All das wird dir abgenommen.

Gruß Jürgen

Aha.

Bedeutet das, dass ich wenn ich z.B. tableadapter.update aufrufe ich dieses nicht in eine Transaktion packen muss?

--------------------------------------------------------------
/Edit um 15:16 Uhr
Habe jetzt das Problem, dass der Updatebefehl keine änderungen durchführt.

Habe ein Formular mit Textfeldern und diese sind an die einzelnen Tabellenfelder angebunden.

Code siehts so aus beim speichern:
[highlight=vbnet]
Me.Validate()
Me.BindingSource.EndEdit()

If Me.DataSet.HasChanges(DataRowState.Modified) Then
Me.TableAdapter.Update(DataSet.tabelle)
end if[/highlight]

Komischerweise ist Me.DataSet.HasChanges(DataRowState.Modified) immer wahr, welbst wenn ich keine änderungen durchführe.

[Jürgen Thomas]

Habe jetzt das Problem, dass der Updatebefehl keine änderungen durchführt.

Wo ist bloß meine Glaskugel... Wie sieht der SELECT-Befehl aus, wie sehen die Speichern-Befehle aus?

Ich weiß jetzt nicht, ob das in deinen Diskussionen schon angesprochen worden ist: SELECT darf keinen JOIN enthalten, der PrimaryKey muss in der Liste der Spalten benutzt werden. Nur dann kann der TableAdapter die Speichern-Befehle automatisch erstellen.

Habe ein Formular mit Textfeldern und diese sind an die einzelnen Tabellenfelder angebunden....

Das sieht im Prinzip sauber aus.

Komischerweise ist Me.DataSet.HasChanges(DataRowState.Modified) immer wahr, welbst wenn ich keine änderungen durchführe.

Das kann u.U. daher kommen, dass beim Einlesen oder Zeilenwechsel manche Änderungen automatisch vorgenommen werden.

Gruß Jürgen

[daribla]

Select enthält den Primärschlüssel und keinen Join.
Update ist der generierte und enthält den Primärschlüssel.

Bei Aufruf des Formulars wird nur die Fill Methode ausgeführt.

[Ralf Jansen]

Du testest ja das Dataset mit HasChanges auf Änderungen nicht die spezielle Tabelle die du da gerade updatest. Hast du andere Tabellen im Dataset die Änderungen vorhalten? Dann solltest du an dieser Stelle auch explizit die Datatable befragen ob sie Änderungen enthält.

z.B mit

If DataSet.tabelle.GetChanges() IsNot Nothing then ....

[daribla]

Du testest ja das Dataset mit HasChanges auf Änderungen nicht die spezielle Tabelle die du da gerade updatest. Hast du andere Tabellen im Dataset die Änderungen vorhalten? Dann solltest du an dieser Stelle auch explizit die Datatable befragen ob sie Änderungen enthält.

z.B mit

If DataSet.tabelle.GetChanges() IsNot Nothing then ....

Bin noch am Anfang des Projektes und habe momentan nur eine Tabelle.

[daribla]

Problem hat sich erledigt, hatte im Tag des Databindings der Formularfelder auch die Tabellenfelder eingetragen, was natürlich falsch war.