Servergeänderte Datensätze

[p80286]

Zitat von Sugar:

Ja, ich greife über ADO auf den SQL Server zu.

Zu deinen Tipps:

Ich muss leider - exakt aus Gründen der Performance - mit ein paar Tabellen arbeiten. Alle sinnvollen Daten hole ich mir natürlich mit AdoQueries. Und, man mag es veraltet halten, aber ohne datensensitive Controls stände ich jetzt vor dem gleichen Problem.

Was eine Mehrzahl von Tabellen mit Performance zu tun hat ist mir schleierhaft.

Zitat von Sugar:

Dein Link, danke dafür, hilft mir nach erster Analyse auch nicht weiter. So wie ich es verstehe, müsste der Client nur woanders nach einer Änderung suchen. Ich "überwache" nur eine andere Tabelle.

Nein, er wird benachrichtigt!

Gruß
K-H

[hoika]

Hallo,
er benutzt TAdoTable, weil es sich so besser mit seinen datensensitiven Elementen (TDBEdit usw.) arbeiten läßt.
Kennt TAdoQuery eigentlich auch das RequestLive ?
Damit klappte war ein TQuery doch fast so gut wir ein TTable.
Hatte ich aber nie benutzt.


Heiko

[Dejan Vu]

Die Problematik schreit eigentlich nach einem Service (aka Mittelschicht). Zugriff auf die Daten über den Service, der dann ja alle Clients benachrichtigen kann.

ADO unterstützt keine Event notifications. Man müsste also den Provider wechseln (AnyDac) oder sich eben den Service selbst schreiben. Fragt sich, was billiger ist

[FBrust]

Hallo,

als kleinere Zwischenlösung könntest Du auch folgendes machen:

- In jeder Tabelle gibt es ein Feld mit Datum/Zeit der letzten Änderung
- Wenn ein Datensatz bearbeitet wird, wird das Feld im Client zwischengespeichert
- Bevor ein Datensatz dann gespeichert werden soll, wird das Datum der letzten Änderung nochmal
aus der Datenbank gelesen und mit dem zwischengespeicherten verglichen
- Ist das Datum unterschiedlich, wurde der Datensatz in der Zwischenzeit geändert

oder Du setzt beim "Holen" eines Datensatzes ein Feld in der Tabelle, das allen
anderen signalisiert, dass der Datensatz gesperrt ist (dann kannst Du auch hinterlegen, von wem und seit wann)

Aber ein Service ist langfristig natürlich die bessere Wahl.

Gruß
Frank

[TheMiller]

Du könntest auch sog. MessageQueues benutzen. Die Windows-Server haben die MS-MessageQueue mit an Board, welche man über die Serververwaltung nachinstallieren kann. Jedes Windows-OS ab 7 aufwärts (glaube ich), hat dieses Feature als Server auch integriert (bzw. ist nachinstallierbar).

Ansonsten kannst du auch RabbitMQ / ApacheMQ verwenden, wenn du eine Linux-VM erstellen kannst.

Dann kannst du bei jeder Änderung eine Nachricht an die MessageQueue schicken, welche alle aktiven Clients benachrichtigt.

Alternativ kannst du auch - wenn es nur um die Meldung geänderter Datensätze aus einem Modul geht - einen TCP-Server u Client verwenden und nach dem Ändern eines DS eine Broadcast-Message (oder alle aktiven Clients) via TCP/IP ansprechen und den String "/reload-1234" senden. Beim Empfangen wissen die TCP-Clients, dass die den DS 1234 aktualisieren müssen.

[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?

[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.