TurboDB sperrt automatisch den Datensatz, wenn ein Anwender mit dem Editiern beginnt. Das verhindert, dass zwei Anwender denselben Datensatz gleichzeitig bearbeiten. Die Sperre wird aufgehoben wenn der Anwender die Änderung bestätigt (Post) oder Rückgängig macht (Cancel) oder wenn er die Tabelle schließt.
Wenn ein Anwender einen gesperrten Datensatz editieren möchte, wird ein Fheler zurücgegeben und der Anwender kann den Datensatz nicht ändern. Die meisten Komponenten-Bibliotheken (z.B VCL/CLX) werfen eine Exception falls der Fehler auftritt.
In TurboDB können Satzsperren neben Tabellensperren auftreten. Es ist möglich, dass ein Anwender beginnt einen Datensatz zu editieren und ein zweiter führt ein Update Statement auf die Tabelle aus, bevor der erste Anwender seine Änderung geschrieben hat. Das geht gut, solange das Update nicht den gesperrten Datensatz tangiert. Falls es das tut, wird das Update scheitern. In beiden Fällen kann der editierende Anwender die durchgeführten Änderungen schreiben.
Automatische Datensatzsperren sind eine gute Sache um die Datenkonsistenz zu bewahren. Sie können aber auch zu Problemen führen, falls eine Sperre nicht mehr aufgehoben wird. Das kann passieren, wenn ein Anwender beginnt einen Datensatz zu editieren und dann in Ferien fährt (ohne vorher die Änderung zurückzuschreiben) oder die Anwendung abstürzt. Falls eine Anwendung unanständig beendet wird, z.B. durch eine Exception, Killen des Tasks, Stromausfall oder durch Abschalten des Computers, bleibt die Satzsperre aufrecht erhalten (Gespeiochert in der *.net Datei der Tabelle). Andere Anwender können den betreffenden Datensatz nicht mehr bearbeiten.
Um das zu verhindern, muss der Anwendungs-Programmierer sicherstellen, dass beim Programmende alle Tabellen ordentlich geschlossen werden. Das wird erreicht durch entsprechendes Abfangen eventuell auftretender Ausnahmen, z.B. durch den Einsatz von try..finally Blöcken um den Code, der zum Editieren von Datensätzen führt und durch Einsatz eines globalen Exception Handlers, der alle Tabellen der Anwendung beim Programmende schließt.
Aber auch das beste Programm kann nicht mit Stromausfällen oder Task Kills zurechtkommen, die aufgeführten Methoden können eine hängengebliebene Satzsperre nicht verhindern. Wenn es also passiert, was ist zu tun?
1. Erste Hilfe: Alle Anwendungen schließen, die auf den Datensatz zugreifen und starten Sie die Anwendungen neu. TurboDB wird die Net-Datei löschen und alles ist wieder neu. (Anmerkung: TurboDB 3.x löscht die Net-Dateien nicht automatisch, Sie müssen dies von Hand erledigen.)
2. Weisen Sie jedem User eine eindeutige Connection Id zu, die bei jedem Neustart wiederhergestellt wird. Standardmäßig bestimmt TurboDB eine zufällige Connection Id, was dazu führt, dass die eigenen Sperren für die eines anderen Users identifiziert werden. Wenn Sie bei jedem Neustart dieselbe Connection Id zuweisen, wird die Anwendung die existierenden Sperren wieder erkennen und ordentlich aufheben. Es ist also sehr wichtig eine eindeutige Connection Id für jeden Anwender zu haben.
3. Sie können ein kleines Programm schreiben, das die Identität der abgestürzten Anwendung übernimmt und die Satzsperren entfernt. Bestimmen Sie dazu die Connetion Id der gesperrten Anwendung mit dem Utility TdbLocks und weisen Sie die Id der Datenbank-Komponente zu.
Für einige Anwendungen mit sehr vielen Usern in einem losen Netzwerk (z.B. Web-Anwendungen), ist es keine gute Idee Datensatzsperren aufrechtzuerhalten während der Anwender den Satz editiert. In diesm Fall sollte ein unverbundenes Datenzugriffsmodell bevorzugt werden.