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.