>I can't find a good reason for pessimistic table buffering, but what about row buffering? How often can a good business case be made for two users editing the same record at the same time? Very few, therefore, if a user goes to change data and the application tests for a lock and can't get it then there is a good reason for it: In use by another.

Ummm, yes and no. "In use by another" may /often does not mean "Being edited by another". I may on the phone with a customer looking up information and somebody in A/R may be wanting to "Edit" the information. With pessimistic row buffering they can't even position themselves on the record :(


>You can't trap this proactively with optimistic buffering.

Sure you can...

OPTION 1:
In your save routine. Test all field states and if any were changed by another user the prompt the users with:

Field "yadda" was changed!
Another user set it to: xxxx
You set it to: yyyy
Accept your value?

Yes No

OPTION 2:
Or, if you wanted to be a bit more primative, you could put an "inuseby" field in the table that is set to the user's code when accessed and set to '' or NULL when the user moves off it. Then in your code you can disableall() bound controls and the Save button if a users hits a record with
!EMPTY(inuseby). To avert false inuseby locks due to "Illegal Operation...MS Windows screwed up, but call somebody else...your system will shutdown" you can put an "Unlock" button on the screen that clears the inuseby flag.

With either method at least more than one user can *access* the record at the same time :)


>Now, with views, of course, all this goes out the door and I agree 100% with you.

Yes and no...because with a view you need to do one of the above anyway because the possibility exists two users could change the same record at the same time and you have no way of knowing it without looking for it. That being the case I aways set my views to update Key and "Modified" fields as opposed to Key and "Updateable" fields...cuts down on possible areas of contention. But still and all, the possibility exits and you need to CYA in code.