TurboDB Engine Documentation
Record Locks
Previous  Top  Next


TurboDB automatically locks a record when a user begins to edit it. This prevents two different users working on the same record in the database at the same time. The lock is removed when the user commits or cancel his changes or when he closes the table.

When a user tries to access a record which is already locked by another user, the call returns an error and the record cannot be edited by the second user. Most component libraries (e.g. VCL and CLX) issue an exception, if this error occurs. The user must wait until the first user has finished editing and then try again.

In TurboDB record locks can coexist with table locks. It is possible that one user starts editing a record and than another user runs an update command against the table before the first user posts his changes. This will work fine as long as the update command does not touch the locked record. If it does the update command will fail. In both cases the first user can edit the record and post it any time afterwards.

Automatic record locks are a great thing to provide data consistency. But they can also be problematic, if for some reason a lock is not removed timely. This can happen because the user begins editing a record and then leaves for holidays or by an application crash. If an application is terminated ungracefully, i.e. by an exception, by an Abort command, by killing the task or by a power failure, the record lock (which is stored in the net-file of the table) persists and other users can no more modify the record in question.

To prevent this, the application programmer must assure that all database tables are closed properly at application shut-down. This can be done by handling all exceptions properly, e.g. using try ... finally ... clauses around record editing code, by avoiding hard program exists and by implementing a global exception handler which closes all databases of the application.

Since the best program cannot handle task killing or power failure, these measures cannot prevent a "hanging" record lock completely. If it still happens, what can you do?
1. First-aid: Close all applications accessing the record and restart them. TurboDB will delete the net-file and you have fresh start. (Note: TurboDB 3.x didn't delete the net-file automatically and you had to do this manually when all applications were closed.)
2. Assign a unique connection id to every user, which is restored at start-up. By default TurboDB determines a random user id at start-up, which means that it regards its own locks from a previous start as the locks of somebody other. If you assign the same connection id each time the application starts, it will re-use the existing locks and remove them properly. Note: It is of great importance to have a unique connection id for each user!
3. You can write a small program which assumes the identity of the crashed application and removes the lock. Do this by determining the connection id of the locking application using the TdbLocks utility and by assigning this connection id to the database component.

For some applications with a lot of users and a loose network connection (e.g. Web applications), keeping a record lock while the user edits the record is not a good idea. In this case you should prefer a disconnected data access model.