Hi Jim,

Thanks for your assistance. The problem with pessimistic buffering is that the VFP message is not displayed until the 2nd user actually tries to edit the record that is locked by another. These folks want the form to simply shut down before the user can even type a key and receive that message. That implies the use of RLOCK() to lock the record by user 1 and to check for user 2 so that the form can be shut down for user 2. Also, pessimistic locking is not going to trigger when class properties are used as control sources because the the actual data buffer is never changed to trigger the lock. The last remaining issue here is that the they are requesting that the master and all of the children (remember, up to 6 forms could be on the desktop each with it's own private datasession) be locked also.

Thanks,
Steve

>Hi Steve,
>
>I'm at a loss too.
>
>But with pessimistic buffering, I don't see the need for a RLOCK().
>
>I still wonder if TRANSACTION has something to do with it.
>
>Good Luck,
>
>Jim N
>
>>>Hi Steve,
>>>
>>>Can you try the program after (temporarily) removing the TRANSACTION business?
>>>
>>>I saw nothing in the Help restricting TRANSACTION processing to BUFFERED stuff, but as we know from other omissions in Help, it might well turn out to bre such.
>>>
>>>I agree that it is perplexing. Do you perchance "play" with the MULTILOCKS setting at all - it will do an implicit UNLOCK ALL if manipulated after some LOCK(s) have been set.
>>>
>>>Good Luck,
>>>
>>>Jim N
>>
>>I set the multilocks in a method that fires for each form that is loaded when it has a private datasession. The whole environment is set only that once. If anything, I might change set deleted as they want to view deleted records.
>>
>>But now with up to 6 forms loading at once, you don't suppose that setting "multilocks" with each successive form load causes havoc in another private datasession do you? That sounds weird to me.
>>
>>Steve