>Hi Steve,
>
>Yes, I saw *after* I wrote (in another message you wrote) that you are not operating on the actual table data directly.
>
>This looks like it should work for you, but based on both yours and Marc's (interesting how some problems seem to come in bunches), I would have to surmise that there is some rule somewhere, and apparently not documented for us, which is being violated.
>
>As a last resort you could, I suppose, keep a small table of RECNO()s you are operating on (deleting when finished operations) which could then be checked *before* you begin processing another record. If the same RECNO() was in that table, you would tell the user you cannot right now, else you would add it to that table and go ahead and process. A pain, but overhead should be relatively light.
>
>Good Luck,
>
>Jim N

Jim,

You're right, in my case that could work of course, but it seems an awful lot of work when one considers that unlock just should do it. But I think I will add something like you discribe to my framework. With your permission, I will add the table and the key i.o. the recno() :).

Thanks again. You certainly pointed me in the right direction.

Marc

>
>>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