>>>>>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.
>>>>
>>>>Hi Colin,
>>>>
>>>>The others have all provided good answers and as you can see, they can be quite varied. I've had to do an app with the same requirements, pessimistic buffering
>>>>and wanting to let a user know that a record is locked. As you've undoubtedly found out, a record retrieved by a user with pessimistic buffering on does not lock that record until they attempt to modify it. I found this rather lacking and my requirements specifically stated that a second user was not to be able to begin editing if the record was in use by another. So I do have a combination of private datasessions, pessimistic buffering and also make use of RLOCK(). When a record is retrieved for editing, I attempt to gain a lock on it. If that user gets the lock, then they have it. If they don't get the lock, I set the .Enabled properties to .F. The user can view the data but cannot change it. It seems to be working fine.
>>>>
>>>>Steve Despres
>>>
>>>I tried doing this and by putting the following in the .Click of my Edit button:
>>>
>>>IF RLOCK()
>>> && Enable=.T. for objects and .SetFocus to first object
>>>ELSE
>>> =MESSAGEBOX("Record is being edited by another user.",(0+48+0),"Cannot Edit")
>>> RETURN
>>>ENDIF
>>>
>>>If I run 2 instances of the form in VFP this code works perfectly. However, when running the .EXE, if a user chooses to edit a record already LOCKed the locks up instead of showing the message. When the first user UNLOCK's the record the other users form becomes active again and is in edit mode. Am I missing a setting or something?
>>
>>Sounds like you are forgetting to set REPROCESS. Remember that like other data settings, REPROCESS is scoped to the current datasession.
>
>I just discovered this running 2 sessions of VFP opening the same table. REPROCESS was SET to 0 by default in both sessions. I locked a record in one session and when I issued RLOCK() in the second the status bar showed 'Attempting to lock... Press ESC to cancel'. I waited for quite a while, go fed up and pressed {ESC}. Then I SET REPROCESS TO 1 SECOND and 1 second after attempting RLOCK() it came back with .F.
>
>By default, how long does VFP attempt to lock a record? Obviosly, to long.

That's what the REPROCESS setting specifies. The default setting is 0, which means VFP keeps trying until it obtains the lock. I usually use AUTOMATIC, which is the same as 0, but allows the user to escape. Check the help under REPROCESS.