I do an APPEND BLANK then a RLOCK(). The reason for locking is that the newly appended record often appears in other users sessions even before it is TABLEUPDATEd.
--George

>When are you doing the LOCK ? After the TABLEUPDATE ? Are you insuring you are sitting on the correct record before attempting the LOCK (after TABLEUPDATE) ? I'm not sure that you are insured of being on the "inserted" record if you simply do an INSERT, TABLEUPDATE and LOCK, with ROW buffering.
>
>Displaying the "current record number" after each operation should give you some idea what is going on, particularly with Grids which tend to do some "syncing" on their own.
>
>And attempting an INSERT, then a LOCK, and then a TABLEUPDATE, on a buffered row, is not an valid operation sequence (IMO).
>
>>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?