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.

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.

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.

>How exactly do you "deal with contention issues"? If two people are allowed to edit the same record, and they both make a bunch of changes, what's the fair way of deciding who gets to keep theirs? Seems easier to me to just not allow a person to edit while someone else is... Unless I'm missing something?
>
>Thanks,
>
>Michelle
>
>
>>There aren't a lot of cases where you need to do this. Unless the probability of two users editing the same record is fairly high, or there's some other reason you need to keep a record locked while it's being edited, I would just use buffering. Then, check the result of TABLEUPDATE and deal with contention issues if it returns .F.