|
|
|
FairCom DB does not force you to acquire write locks before updating a record. It is up to you to use LockISAM() or LockCtData() in a manner that preserves data integrity. Updating a record without first obtaining a write lock runs the risk of having multiple users trying to update the record at the same time. If two users try to write to a record at the same time, the first value written will be overwritten by the second, and the validity of the data is compromised.
The ctCHECKLOCK file mode has been provided to aid you in this matter. If you OR it in with the other file mode values when you open or create a file, FairCom DB will require that you have a write lock on a record before it can be updated. If you do not, then the update function will return an error code of DADV_ERR (57).
If you specify ctCHECKLOCK at the time the file is created, that mode will be invoked every time that you open the file. It becomes a permanent part of the file’s attributes. If it was not specified at file creation, you can OR in the value at file open.
As discussed in “Data Integrity”, when using transaction processing you can automatically invoke LockISAM() for all ISAM update functions by OR-ing a lock mode into the argument of the Begin() function.
ctCHECKLOCK can be used in multi-user standalone (FPUTFGET) mode.
Note: ctCHECKLOCK and ctCHECKREAD are intended as debugging aids to help developers to identify code locations where locks are not being acquired.
ctCHECKREAD is not compatible with ctSUSPEND by definition because ctSUSPEND will disable record lock acquisition without releasing existing locks, so any record read would then trigger the ctCHECKREAD error condition.
ctCHECKLOCK and ctCHECKREAD should not be applied to index files.
