>>>>>After making the jump from FoxPro 2.5 to VFP5 I am starting to understand the aspects of buffering and data sessions. In 2.5 I simply used RLOCK() for record locking. If .T. SHOW GETS ENABLED, if false then a message stating that the record is being edited by another user. In VFP my form's DataSession is set to 2-Private and the BufferModeOverride of my cursor in the DE is set to Pessimistic Record Locking. How do I implement the same type of record lock checking in this situation.
>>>>
>>>>My preference is to use Optimistic Buffering. But then your dealing with a different set of problems. Finding out if a change has been made to the data before flushing the change. You will be using TABLEUPDATE(). I would browse the KB. See if they can give you a more precise answer.
>>>>
>>>>HTH
>>>
>>>I don't use Optimistic because my users want to know as they choose edit that someone else is editing the record. VFP documentation states that private data sessions are supposed to respect the record locking of the table they represent. However, if one user is editing a record, the ISRLOCKED() function returns .F. on another users machine for that record.
>>
>>I use optimistic buffering. In my edit buttons class, the save button code is wrapped with:
>>if RLOCK()
>>*whatever code here
>>else
>> =MESSAGEBOX("Can't edit. Record is in use by another.",48+0+0,gcAppname)
>>endif
>>
>>then I just issue an UNLOCK after the TABLEUPDATE() or TABLEREVERT() in the save and undo buttons, respectively.
>>
>>Make sure you set REPROCESS to the desired setting (depending on what behavior you want).
>>
>>In short, I guess RLOCK works pretty much the same as it did in your old apps, even with buffering set.
>
>What's the idea lays behind using RLOCK() and optimistic buffering together? Actually, optimistic buffering assumes no-lock on record during editing, i.e. you will never return .f. from RLOCK(), except the case when 2 people press 'Save' at the same time, and this point could be handled by optimistic lock mechanism itself.

I guess it is just so I can control what message the user sees and when she sees it. With pessimistic buffering, the user doesn't know that the record is in use until he actually tries to edit one of the fields. With my method, the edit button checks to see if the record is in use instead of waiting for the user to try to type. Maybe not the best way, but was the best way that I found, and has worked well for me.