>>>>>>>I have the following problem. (Buffering is 3 – Optimistic row buffering is on)
>>>>>>>Sue enters a new record and locks it. Bill enters a new record and attempts also to RLOCK() but the lock fails.
>>>>>>>I suspend Sue's process and browse the table. The record she inserted has moved up by one and she is now sitting on Bill's new record and has it locked.
>>>>>>>I can reproduce this. Can anyone help with this?
>>>>>>It'd be interesting to see a reproducing code.
>>>>>>Why do you need an insert followed by a lock ? You say it's row buffered. It wouldn't go on to disk till you leave the record or explicitly tableupdate.
>>>>>>You might be more comfortable with buffering 5.
>>>>>>Cetin
>>>>>To reproduce this all I need to do is to have 2 users try to insert at the same time.
>>>>>I introduced locking because users were complaining that occasionally when 2 of them wereinserting at the same time that one will suddenly start editing the other's record.
>>>>>In the above, I changed to table locking but get the same error, the only difference is that I do not see Bill's record in Sue's session.
>>>>Table locking ? I meant buffering.
>>>>Cetin
>>>Sorry, I meant table buffering.
>>Sorry then. I don't know of a way to get another buffered table's (in buffer) record unless I can switch to its workarea. Without being able to reproduce no idea.
>
>George, I _have_ seen this before, and managed to trim it down to a very simple repro. Unfortunately, I can't figure out what that was. Can you post code that will show the behavior? It's been ticking me off since VFP3.

The code is very simple:

SET MULTILOCK ON
USE CUSTOMER
=CURSORSETPROP("Buffering", 3)
APPEND BLANK
?RLOCK()

Now start another session of VFP and run the same code. The lock will fail.

--George