Record Locking

 

<< Click to Display Table of Contents >>

Navigation:  Getting Started >

 

Record Locking

 

Previous pageReturn to chapter overviewNext page

 

 

 

By default Btrieve uses optimistic record locking. We have implemented the BtServer and BtTable class to use this optimistic locking. If you want to override this, you can call the Rlock methods on these classes to manually lock the records. You are then also responsible for unlocking the records yourself. If you fail to do so you will keep the record(s) locked until you close the table.

 

By Default VO2Btrieve runs an application was under ONE Btrieve client ID. This can cause problems when you open the same file twice, for example on 2 windows and are locking the same record twice. Btrieve would return true on the second Rlocks even if it was already locked by another window.

If you would try the same from within two applications locking the same record the second time would not succeed.

 

We have added some functionality to allow multiple 'Clients' in the same application. Each client has its own unique ID number. After setting this ID all files opened will belong to this ID, unless another ID is specified when opening the file (all File classes have an extra ID parameter) or the global Id is changed. If one 'Client' has locked a record another 'Client' within the same application can not lock the record anymore.

 

If you do not use this technique, Rlocks of the same record will succeed, but updating the same record twice is still prohibited by the Btrieve Engine. This will result in an error 80 (Record changed by another). The same happens if you don't lock at all (and use btrieve's optimistic locking scheme) and update the same record from 2 different servers.

 

See the Locking sample for more information