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

Wow........quite a response. I hope that you got the info you were looking for.
I hadn't thought about Jim Booth's reply regarding optimistic buffering and handling things after that. I did have to write an app for someone where they were insisting that a 2nd user have their form shut down, all controls disabled, before any keystrokes could be made. As Ed suggested....I threw out buffering and went with properties of datamgr classes being set as the control sources on forms. This is like the old way of using memvars but with explicit property mapping, one doesn't run into the SCATTER/GATHER scoping issues alluded to by Mr. Booth. No buffering allowed my to do RLOCK() but there were several problems with that too. If you look back a couple of weeks, you'll find a message by me with a number of replies regarding RLOCK(). It didn't work as smoothly as one would have suspected. Transaction processing is still possible with buffering though.

Steve