Record locks

Applications can acquire record locks at record retrieval time. Most BDE functions that are capable of fetching a record provide the option of locking; for example, DbiGetNextRecord, DbiGetPriorRecord, and DbiGetRelativeRecord. The eLock parameter can be used to specify one of the following record locks:

Setting	Description
dbiNOLOCK	No lock; allows other users to read, update, and lock the record
dbiREADLOCK	Upgraded to a write lock
dbiWRITELOCK	Allows other users to read the record, but prevents them from updating the record, or placing a lock on the record

Paradox and dBASE lock managers both upgrade read locks to write locks; so, in effect, a record is either locked or not locked.

Because some BDE record-fetching functions perform operations other than locking, the order in which these operations occur can be significant:

•Cursor movement always occurs first.

•Paradox and dBASE drivers attempt to lock the record before filling the record buffer.

•SQL drivers fill the client's record buffer and then attempt to lock the record.

Note:

Cursor movement occurs even if the lock fails. For example, if DbiGetNextRecord is called with a read lock, the cursor moves to the next record, and the lock is then attempted. If the record is already locked by another user, the lock attempt fails, but the cursor has changed position.

Maximum number of record locks for standard tables

Shared dBASE table 100

Shared Paradox table 255

Checking a record's lock status

To check the lock status of a record, use DbiIsRecordLocked. This function returns the lock status of the current record; the lock status can be either locked or not locked.

Releasing record locks

The application can call the function DbiRelRecordLock to release the record lock on the current record or release all the record locks acquired in the current session. In addition, DbiModifyRecord provides an option to release the lock after the operation has completed.