Servergeänderte Datensätze

[Sir Rufo]

Der MS-SQL-Server kennt den Feldtyp RowVersion von daher braucht man sich dort nicht mit einem Timestamp herumärgern.

[mm1256]

Zitat von Sugar:

Vielen Dank an alle. Also, die Anwendung ist mir für eine Investition in andere Zugriffskomponenten einfach zu minimal.

Ich würde mir aber gerne mal die Lösung mit dem Service, wenigstens in der Theorie, ansehen. Kennt einer hilfreiche Links oder andere Quellen (democode) dazu?

Den Service selber zu programmieren würde ich nicht machen. Der Aufwand ist viel zu hoch. Folglich müsstest du hier auch wieder auf Komponenten von Drittanbietern zurückgreifen, z.B. das Trio Aurelius/Sparkle/XData von TMS.

Auch wenn es aus technischer Sicht nicht vom Feinsten und State of the Art ist, würde ich in diesem speziellen Fall (soweit ich dies anhand der verfügbaren Informationen beurteilen kann) mit einer Variante der bereits vorgeschlagenen Lock-Mechanismen arbeiten. Entweder eine separate Lock-Tabelle, oder entsprechende Lock-Felder bei den Datensätzen. Das einzig knifflige Problem dabei ist, wie man mit Verbindungsabbrüchen umgeht. Ein Client lockt, und verabschiedet sich. Wer hebt den Lockmechanismus dann wieder auf? Ist also auch nicht das gelbe vom Ei.

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. Ich verwende ihn teilweise heute noch. Es ist quasi eine "lokal auf dem Client arbeitende Mittelschicht".

Es werden insgesamt 3 Datenpuffer verwendet:

- Bei Beginn des Editiervorganges wird der Inhalt des aktuellen Datensatzes in Puffer 1 gelesen
- Puffer 1 wird in Puffer 2 kopiert, das ist der Editierpuffer mit dem der User arbeitet
- Nach dem Editieren und vor dem Post wird Puffer 2 mit Puffer 1 verglichen. Besteht kein Unterschied (der User hat nichts geändert) muss in der DB nicht gepostet werden. Man spart sich also den Post. Andernfalls wird Puffer 3 vom aktuellen Datensatz aus der DB gelesen und mit Puffer 2 verglichen
- Ist der Vergleich positiv (beide Puffer sind gleich) hat womöglich ein anderer User bereits die selben Änderungen vorgenommen. Man spart sich also wieder den Post. Bei negativem Vergleich kann man dem User dann wahlweise

a) die geänderten Daten aus Puffer 3 nochmals zum Editieren anbieten
b) seine eigenen Änderungen verwerfen
c) beide Varianten anzeigen und einen Mix daraus bilden. Das muss im Einzelfall entschieden werden.

Dieses Prinzip hatte für den Arbeitgeber den Vorteil, dass sich die Mitarbeiter nie lange mit dem Editieren aufgehalten haben. Es könnte ja sein, dass ein Anderer "gewinnt". So nebenbei hat man auch ein UnDo während des Editierens.

Für die Erstellung der Puffer braucht man lediglich eine einzige Funktion, dazu dann noch die Vergleichsfunktion, was den Zeitaufwand sehr in Grenzen hält.

[Perlsau]

Wieso ist der Vorschlag, die entsprechende – kostenlose – Event-Komponente von Zeos zu verwenden, inakzeptabel oder nicht diskussionswürdig?

[Dejan Vu]

Zitat von Sir Rufo:

Der MS-SQL-Server kennt den Feldtyp RowVersion von daher braucht man sich dort nicht mit einem Timestamp herumärgern.

Ich dachte auch immer, das der T-SQL Datentyp 'TimeStamp' irgendwas mit der Zeit zu tun hat. Aber in Wirklichkeit ist 'TimeStamp' nur die veraltete Version der RowVersion.

@Perlsau: Vermutlich, weil es nichts zu diskutieren gibt. Funzt. Fertig. Noch Fragen?

[Hansa]

Zitat von mm1256:

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.

[mkinzler]

So funktioniert es grundsätzlich heute auch noch in auf Versionierung basierenden Transaktionssteuerungen.

[Hansa]

Ja, im Prinzip. Aber erkläre das doch mal, wie man die Transaktionen einstellen muss und was sonst noch zu beachten ist. Die Aussage "funktioniert heute noch so", die nützt dem Fragesteller nämlich nichts.

[mkinzler]

Wie es bei dem Produkt vor 30 Jahren war, noch weniger.