Wie wäre es denn mit einem Mechanismus, wie ihn die uralte B-Tree-Shell von EDV-Beratung Enz schon zu DOS-Zeiten verwendet hat.
Uff, das kennt hier noch jemand ?
Ja, die Basis war die Btree-Isam vom Dipl.-Mathematiker Ralph Nagel. Die angesprochene Zwischenschicht war dann die Btree-Shell. Die kam aber erst dank
OOP. War schon cool. Leider ging die Fa. Enz wegen Delphi 1 pleite. Warum ? Wohl weil ein Haupt-Umsatzträger Object Professional (TurboPower) war. Da gab es z.B. brauchbare Editfelder usw. So etwas war dann aber bei Delphi dann auch von Anfang an dabei. Ich kenne Enz und Nagel. Die gingen beide zu KHK (heute Sage). Es gab ja auch deutsche (gedruckte) Handbücher. Übersetzung, Drucken usw. das war wohl auch letztenendes zu teuer. Schade.
Aber zum Thema : Grundlage waren prinzipiell 3 Datensatzversionen. Genannt Savebuffer, Workbuffer und Tempbuffer. Beim Lesen eines Datensatzes werden Savebuffer und Workbuffer mit dem gelesenen Datensatz gefüllt. Savebuffer dient dabei zum späteren Vergleich auf zwischenzeitlich von anderem User durchgeführte Änderungen. Workbuffer ist das, was gerade z.B. editiert wird.
Beim Abspeichern (wäre dann das im Workbuffer) hat die Btree-Shell automatisch den momentanen Datensatz-Inhalt auf der Festplatte in den Tempbuffer eingelesen. Wenn nun Savebuffer (also quasi alter Zustand) und Tempbuffer (Zustand beim Abspeichern, also später) Differenzen aufwiesen, z.B. weil anderer User schneller war, dann wurde die Variable IGAlreadyChanged auf true gesetzt und man konnte reagieren.
Das hiesse dann, man überschreibt die von anderen gemachten Änderungen, oder speichert nicht oder es werden nur einzelne Felder geändert und dann wird gespeichert. Für letzteres u.ä. gab es viele Funktionen. Tja, finde das Prinzip immer noch wasserdicht.