Sorry, I haven't such deep technical background on locking schemes.t57042 wrote: The record is indeed locked just before writing to disk.
This is called ‘postlock’ or ‘optimistic’ locking. In this scenario user2 can update a record which is currently edited by user1. When user1 writes his update to disk, user2’s is lost.
The advantage of this method is that the record is only locked for a very short duration.
The disadvantage is possible lost update (can be overcome by reading back the record just before updating and comparing it with the saved original version - when both are equal write is ok)
The method used by the BROWSE command is ‘prelock’ or ‘pessimistic’ locking.
As soon as one user reads a record to update it that record is locked. It stays locked as long as it has not been written back to disk.
The ‘lost update of the other method is avoided.
A disadvantage is that records could be locked longer.
What I would like is the second method implemented in the EDIT EXTENDED code.
IMO this is wrong. Because if record locking applied when one user intent editing a record, no other users can access this record while editing process continue. And editing process may take long time; for example user may go to another job and left open that editing.the lock should be made at the moment the intention of editing (or adding/ deleting) is given.
As the result, record locking implementation of both EDIT EXTENDED and BROWSE are perfect for me.
As course, you can select and do any method you like into your code.