>>>>>Fred, we had the same problem because our 3rd Party framework opened all the tables in the default DS and then used "USE AGAIN..." in the Private DS. Even after emptying out the default DS, we still had to USE the tables to make sure we had the most accurate data.
>>>>>
>>>>>Network caches, especially write caches can cause these problems as well.
>>>>>
>>>>>HTH
>>>>>Barbara
>>>>>
>>>>>>I have gotten flacky results with pessimistic row buffering. I have an app where we need to lock the record while a user is editting it. We have set the table to pessimistic row buffering and the edit forms. We have been able to have two users editting the same record. Is it us, or a bug?
>>>>>>
>>>>>>We don't want to test all of the fields because the clerks get a list of all record changes in the morning and they just work down the list until all of the changes are made. If a clerk cannot edit a record, they mark it on the form and move on. FPW26 it was easy.
>>>>>>
>>>>>> Are we not using pessimistic row buffering correctly?
>>>>
>>>>Also remember that pessimistic buffering does not "lock" any given record until a user actually begins to edit it. This means that two users can bring up the same record on a form and be given the false impression that each can start editing. User 1 starts and when user 2 starts, user 2 get the message.
>>>>
>>>>Steve
>>>
>>>Steve:
>>> That is exactly what we are seeing. Will RLOCK() lock the buffered record or the record in the table? I cannot find any documentation that gives a clear answer.
>>>
>>>Do we have to place an Edit Flag in the Record?
>>>
>>>Help
>>
>>You should make a choice: if you use RLOCK() then you don't need in buffering at all.
>
>I wouldn't say that Ed. You still need buffering to use TABLEUPDATE() and TABLEREVERT().

If you use RLOCK(), then you need in neither buffering nor tableupdate/revert. If record is locked by you, then nobody else will change it, right? So, what helpful information you may get from buffer?