Locks a table.



Sub LockTable(ByVal hTable As Long, ByVal Wait As Boolean)

The handle to the table.

This parameter is used to indicate whether the lock should be with or without wait:




The lock will be with wait


The lock will be without wait



' lock table

  CF1.OpenTemporaryTable hTable, 15



  CF1.LockTable hTable, False

  logWr "LockTable (NoWait) OK"

  CF1.LockTable hTable, True

  logWr "LockTable (Wait) OK"



LockTable locks a table to protect it from conflicting write operations. You can only use LockTable inside a transaction (inside BWT and EWT). The differences between using Wait or not using it are:

If another application is carrying out a transaction on the table when you issue this lock, the function suspends your operations and waits until the table is available before returning.

If another application is carrying out a transaction on the table when you issue this lock, the function raises an exception and calls the exception handler.

The C/SIDE database system uses table locking to ensure data integrity. Whenever an application begins to change data in a table (with InsertRec/ModifyRec/DeleteRec), the table is automatically locked. The lock prevents all other applications from changing data in the same table and remains active until the write transaction is ended (or aborted) with EWT or AWT.

Table locking does not prevent any authorized users from gaining read access to the table.

Because all write operations automatically lock the table in question, a call to LockTable would seem to be unnecessary. Imagine, however, a transaction in which an application wants to inspect data before possibly (though not necessarily) changing it – and have a guarantee that the data it changes has not been altered since it was read. The solution is to lock the table before reading, thereby ensuring that no other application can change the data between your reading the data and performing the possible write transaction.

The C/SIDE database system provides deadlock detection. Let us say that two applications, A and B, simultaneously want to lock the same two tables but in reverse order. Thus A locks Table 1 and waits to lock Table 2, while B locks Table 2 and waits to lock Table 1. This potentially fatal situation is called a deadlock and is automatically detected by the C/SIDE database manager. One of the applications will raise an exception and be terminated, while the other will be allowed to continue.

© 2009 Microsoft Corporation. All rights reserved.