>I seem to have solved most of these by switching buffering from 5 to 3 just >prior to the update cycle, and resetting on completion. I also force a seek on >each of the tables, as I am not sure that in locking the records I have the >most current version. All of the Fox books are quite vague on this.

>Suppose two users have the same record. One locks, updates,and releases his >copy. The other finishes his phone call, and then goes through the same >process.
>If locking, or changing the buffering to 3 refreshes the user copy in the >process all is well. If not, there is a problem.

Buffering 3 and 5 behave the same unless you move the record pointer after you have made changes. What I mean by this is, all the changes are buffered in memory and nothing is commited to the underlying table or view until you do something. That something is different for the different settings. Both records will be updated (or an attempt will be made) if you issue an explicit tableupdate(). However, if you move the record pointer while using 3, then VFP will issue an implicit tableupdate(). Because it is implicit, you aren't capturing the results. If an error occurs, your error trap may catch it and that would be the only way of knowing something had happened.

I like error traps for those things I can't predict. I don't like using them if there is another way and the VFP gives me another way. I can control this, so I do.

Don't get me wrong. I have no problem with using 3 in a single record update situation. As long as you use a tableupdate() when you are done making changes. I don't like it because I use a lot of parent-child relationships. I need table buffering on my child table because I will most likely add more than one child record and I don't want records in the child table before I commit the addition/changes to the parent table. I also like consistency so if I use 5 on the child, I use 5 on the parent.

To your scenario. If the system is written using explicit tableupdates then the second user's will return .F.. VFP will check the underlying table when it attempts to update it, find that it has changed and it won't tableupdate. You can check for this in your save function and display an appropriate message.

Getting a lock on a record before you attempt to tableupdate will refresh your copy of the data. However, what if user #2 changed some of the same fields that user #1 changed. His changes are now lost because you just refreshed his data with what is now in the table. Realistically, you should inform user #2 that the data has changed and the data should be checked again. I don't think optimistic row buffering (3) does this.