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?