Hi Al,

>I'm wondering whether you're chasing problems that are only a result of your testing i.e. they won't be present in the real world:
>

No, the problems showed up in the "real world" first. This testing has come about in my looking for a solution.

>Can you test with 2 separate, networked computers rather than 2 instances of your app on the same computer?
>

All the testing has been done on 2 separate networked computers as well as 2 instances on the same PC.

>You could certainly try FLUSH FORCE as John suggests (i.e. after you obtain your RLOCK() and update the row). But as John also points out, there's no guarantee the file system storing your data will actually respect this command - it could be a Linux box running Samba, a NAS box etc.
>

FLUSH FORCE was the first thing I tried, without success.

>Another thing to bear in mind is that some commands you may be using scope only to a datasession e.g. SET LOCK, SET MULTILOCKS. For a full list see the help for SET DATASESSION.
>

I'll look into this to see if it will have any bearing on what I'm doing.

>Finally, one thing that used to be true years ago with xBASE was that, in a multi-user environment, the only time you could be guaranteed to be accessing current data was after successfully obtaining the appropriate lock - either RLOCK() or FLOCK(). AFAIK this is still the case. If so, with your current design you can't guarantee that the second station can view the first one's updates because the second one cannot get an RLOCK() on the necessary row. One possible workaround would be to use 2 tables:
>
>- table LOCKS has only 1 column, a primary key. Its sole purpose is to hold locks.
>
>- table LOCKDATA has the same PKey column, plus other info columns as needed e.g. user name, computer name etc.
>

Yes, that is where I have reached in my thinking. However, I have been able to duplicate the problem in the framework directly and I believe the framework developers are looking into it. Hopefully they will come up with a suitable solution soon. For now, I am just reporting that the record has been locked, not by whom.

Thanks for your time and suggestions!