Zitat von
Peter Geyer:
Es will einfach nicht in meinen Kopf das, Delphi,
ADO und MMSQL für dieses
"wirklich seltene und fast nie vorkommende" Problem keine Lösung in der Tasche hat.
Es gibt halt für diese Problem keine allgemeingültige Lösung. Je nach Anzahl der Benutzer, der Rount-Trip-Delay-Zeit, der Anzahl der Änderungen pro Zeiteinheit, ... ist die eine oder ander Lösung geeigneter.
Selbst habe ich schon mal eine Lösung auf Basis einen "Lockservers" realisiert.
Wird ein Datensatz zum evtl. bearbeiten geöffnet, so wird der Lockserver angefragt. Erhält der User die Erlaubnis den Eintrag zu sperren, so wird der Dialog im Änderungsmodus geöffnet. Jeder weitere User erhält auf seine Anfrage eine vermerk, das der Datensatz schon zum bearbeiten geöffnet ist.
Das Problem mit evtl. abstürzenden Clients ist nicht gegeben, da der Server ein
DCOM-Objekt war, und
DCOM per "Ping" die existenz der Clients abfrägt und bei nicht mehr erreichen diesen die Sperre zurücknimmt.
Eine Alternative wäre z.B. auch für jede Tabelle eine Zeitstempel-Spalte einzuführen. Damit könnte relativ einfach ohne Serverkomponente vor einem Schreiben gechecket werden, ob sich der Datensatz geändert hat (Der vergleich mit allen Spalten ist problematisch, wenn BLOB/Binary-Felder ins Spiel kommen).
Sperren auf
DB-Ebene ist immer Schlecht, da vor allem beim MS-
SQL-Server u.U. auch reine Lese-Abfragen gesperrt werden.