Datenbankseitiger Rollback auch clientseitig nachvollziehen

[Karsten Strobel]

Hallo,

ich habe eine kleine Anwendung, bei der Daten mehreren, voneinander abhängigen DataTables in Grids editiert werden. Das Updaten der Änderungen über die TableAdapters der beiden Datatabes habe ich in eine DB-Transaktion gekapselt. Wenn ein Constraint verletzt wird, führt dies zu einem Rollback, und die Datenbank bleibt weiterhin konsistent.

Soweit, so gut. Wenn allerdings auf der Clientseite die Updates des ersten TableAdapters noch funktionieren, die vom zweiten TableAdapter jedoch zu einem Fehler und damit Rollback führen, so sind die RowState's der Rows aus der ersten Tabelle (für die das Update noch geklappt hatte) bereits auf Unchanged, obwohl die Änderungen in der Datenbank ja zurückgenommen worden sind..... Wenn also der User jetzt das Problem in der zweiten Tabelle behebt und nochmal speichern will, werden die Änderungen der ersten Tabelle nicht nochmal zum Server geschickt.

Das Problem schein so weit klar zu sein. Nun zur Lösung: Ich hab es noch nicht probiert aber meine Idee wäre, zunächst von beiden DataTables mit .GetChanges() die Änderungen zu holen, den TableAdapters dann mit diesen Änderungen zu füttern statt mit den Original-Tabellen und erst wenn alles geklappt hat AcceptChanges() aufzurufen. Führt das zu Ziel? Gibt es einen besseren Weg?

Danke
K.

[Andreas Kosch]

Hallo Karsten,

Gibt es einen besseren Weg?

ja - wobei der bessere Weg auch noch der einfachere ist ;-)

1. Vor dem Update-Aufruf ein DiffGram sichern: dataSet1.WriteXml(sXmlFileName, XmlWriteMode.DiffGram);
2. Update aufrufen
3. Wenn die Datenbank ein Rollback gemacht hat, das DataSet leeren und das im Schritt 1 gesicherte DiffGram zurückspielen: dataSet1.ReadXml(sXmlFileName, XmlReadMode.DiffGram);

Das DiffGram speichert den aktuellen Zustand des typisierten DataSets, wobei durch das DiffGram-Format auch die DataViewRowState-Werte und die DataRowVersion.Original-Werte mit gesichert werden.