Firebird:deadlock - update conflicts with concurrent update

[Hansa]

Echt lustig, zu lesen, daß es mit dem Lesen angeblich nichts zu tun hat und read_committed den Fehler beseitigt. 8) Da sage ich nur : zu zwangsläufigen Nebenwirkungen fragen sie ihren Apotheker. Ich bleibe dabei : schreibende Ttransaktionen möglichst kurz halten und die lesende abtrennen.

Zitat von Jasocul:

Den Datensatz aktuell nochmal holen und vergleichen, ob er sich geändert hat.

Hat sich geändert -> Daten können nicht geschrieben werden, da DS sich geändert hat.

Keine Änderung -> eigene Änderungen können gespeichert werden.

[/quote]

Das ist etwas zu kurz. Wenn, dann läufts so ab : lesende Transaktion mit Commit. Der Datensatz kann dann solange offen bleiben, wie er will. Aber bevor er endgültig abgespeichert wird : Lock und neu lesen. Neu gelesenen und den vorhandenen vergleichen. Dann weiter wie Du sagst : keine Änderung : speichern, Lock aufheben.

Meine Frage zielte aber darauf hinaus einfach zu erkennen, ob ein Datensatz zwischenzeitlich doch geändert (womöglich sogar gelöscht) wurde. Was wurde wo geändert ? Speziell welche Felder sind betroffen ? Und wie darauf reagieren ? Wurden umfangreiche Änderungen von 2 Leuten durchgeführt, dann wäre es eventuell sogar sinnvoll, gezielt einen neuen Datensatz aus den 2 geänderten zusammenzubauen, bevor komplett alles über den Haufen geworfen wird. IB/FB besitzt einen BDR (Back Difference Record). Vermutlich ist der für sowas gedacht. Aber keiner weiß wie.