First, I always simulate row buffering, even if I'm using table buffering. IMHO, a user isn't going to know what's going on if they've changed 10 records and when you try to update, there's a problem with a record they changed 7 records back. I do a tableupdate whenever the record pointer moves.

I'm already using row buffering.

If there is contention when I try to update, I have a standard form than shows the original value of each field in the record, the value entered by the other user, and the value entered by you. I then offer the option of keeping the other user's changes or overwriting them with your own changes. I have text on the screen that instructs the user that in case they want to save some changes from the other user, to note what those changes are, overwrite with their changes, then re-edit the record, putting in the changes from the other user that they needed to keep.

Goodness, I think all that would confuse them. It's an interesting idea, but I think it's much simpler to just tell them they can't edit the record yet.

In all the VFP apps I've written, I think my users have seen this form come up maybe twice. As I said, there aren't many cases where users would be editing the same record at the same time.

Which is exactly why I don't want to spend a lot of time coming up with fancy screens to handle contention. :) It just won't happen that often, especially since they don't generally have more than one person doing the same job.

Thanks,

Michelle