Moin,

ich habe ein DataSet mit mehreren Tabellen und Relationen. Irgendwann speichert man nach diversen Änderungen (Neuanlage, Löschen, Bearbeiten) und ruft dazu das .Validate() auf, ein .EndEdit() auf alle Bindingsources und lässt mit TableAdapterManager.UpdateAll() alles in der Datenbank (MySql) speichern.
Danach habe ich aber immer noch meine in den Tables des Datasets erzeugten Primärschlüssel von z.B. -1, -2 usw. in den Rows und nicht die Primärschlüssel aus der Datenbank, die ein AutoIncrement hat und daher andere Schlüssel anlegt (10, 20...).
Wie macht Ihr das, wenn Ihr im DataSet nicht noch eine Weile mit den negativen Schlüsseln weiterarbeiten wollt, sondern gerne die Schlüssel der Datenbank im Speicher haben möchtet?
Ich kann nach dem Speichern natürlich alle betroffenen Tabellen mit .Fill() wieder neu aus der DB holen, dann habe ich die DB-Primärschlüssel. So mache ich das aktuell auch.
Gibt es da auch eine andere Möglichkeit - irgendeine Einstellung, dass das TableAdapterManager.UpdateAll() die neuen Schlüssel automatisch aus der DB holt und in die Datensätze übernimmt?
Dass das in Ausnahmefällen für einzelne Datensätze mit LastInsertedID o.ä. geht, ist mir klar, aber damit will ich erst gar nicht anfangen - so highlevel und vom Framwerk unterstützt wie möglich.

Danke & einen schönen Tag noch!
Gruß
Michael

Vielen Dank schon mal vorab, habe ich mir gedacht, dass dazu mal wieder Kreativität gefragt ist - wäre auch zu schön gewesen.
@EDR, danke, ich werde mir das anschauen, aber die Einzeldatensatz-Nachbearbeitung wird es sicher nicht werden, da bleibe ich lieber bei meinem .Fill() nach dem .UpdateAll().
@VB1963: ich habe mit dem Schlüssel nix vor, aber wenn schon Kopie der DB im Speicher, dann doch bitte eine aktuelle, wenn sich eine größere Menge Daten geändert hat. Die Daten an sich sind ja gleich, aber eben die Schlüssel nicht - gefällt mir nicht an dem ganzen Konzept.

Hallo zusammen,

Problem gefunden und erfolgreich einen Workaround gebaut.

Ursache: ein seit mind. Juli 2008 in "MySQL for Visual Studio" (genauer im .NET-Connector) befindlicher Bug, der scheinbar auch nicht so einfach zu bereinigen ist, da Microsoft die ganze TabelAdapter/TableAdapaterManager-Sache mit Hauptfokus MS-SQL-Server entwickelt hat und MySQL es daher etwas schwerer hat, sich einzuklinken.

Der Bug ist beschrieben z.B. hier: bugs.mysql.com/bug.php?id=37865 oder hier: bugs.mysql.com/bug.php?id=70305.

Für MS-SQL ist standardmäßig im "TableAdapter-Konfigurations-Assistent" unter "Erweiterte Optionen" ein Haken bei "Datentabelle aktualisieren" gesetzt. Dort steht:
"Fügt eine Select-Anweisung nach Insert- und Update-Anweisungen hinzu, um Identitätsspalten-, Standard- und andere Werte abzurufen, die von der Datenban berechnet werden."

Bei einer MsSql-DB-Anbindung ist der Haken bis dato nicht gesetzt. Setzt man ihn und lässt den Assistenten durchlaufen, ist er wieder entfernt und der erwünschte SQL-Code, dass nämlich nach dem Einfügen der von der DB generierte PK in die Datensätze zurückgeschrieben wird, steht leider auch nicht z.B. im InsertStatement - das ist der Bug von oben. Bei MS-SQL sieht der erzeugte Code z.B. so aus:


Bis der Bug mal entfernt wird, kann man sich so behelfen, wie im ersten o.g. Link geschrieben:

Z.B. beim Form-Laden die Fix-Methode je Tableadapter aufrufen. Übergeben wird der Adapter eines jeden TableAdapters und die Primärspalte der Zieltabelle des Tableadapters.



Die Fix-Methode selbst:



Danach steht - wie bei MS-SQL - auch nach dem folgenden Code in allen Tabellen der PK aus der Datenbank drin (und nicht mehr die -1, -2... Werte von zuvor) - ohne dass man die Daten mit .Fill() neu nachladen musste.



Fehlermeldungen dieser Art (der Foreign-Key des Childs wurde mit z.B. -1 in die DB geschrieben, da nicht durch den korrekten Key des Masters ersetzt) verschwinden dann auch:
Cannot add or update a child row: a foreign key constraint fails (`userarea`, CONSTRAINT `iduser_1` FOREIGN KEY (`iduser`) REFERENCES `user` (`iduser`) ON DELETE CASCADE ON UPDATE CASCADE)