>But Jim,
>
>Isn't this just as good an agrument *for* the locks (and prevention of simultaneous update by two users in the first place) - if one would most likely never hit the situation, then a bunch of code to try to "arbitrate" some simultaneous change, which *does* include that sticky problem of same-field updated (so who is to "win") may not be that productive. Especially if it doesn't get the detailed testing it would need.
>
>I agree, though, that a C/S environment demands that something along these lines needs to be done.
>
>Regards,
>
Jim,

Your point is well taken, here's my thought process on the issue;

 Strategies
 Pessimistic                   Optimistic
 Effective in preventing 2     Allows 2 users to access the same
 users from accesing the same  record
 record

 Prevents logical data         Prevetns logical data collisions
 collisions

 Can be implemented using      Can only be imlemented using optimistic
 Pessimistic or optimistic     buffering
 buffering

So, if I can imlement the pessmisitic strategy using optimistic buffering and I can do the same for the optimistic strategy, then why would I ever use pessimistic buffering?

You may ask, how do you implement a pessimistic strategy using optimistic buffering? In any of a number of ways.

1) Secure your own locks before allowing and edit to begin
2) Use semaphore locking techniques for the same purpose

Pessmistic buffering take the entire locking strategy out of your hands, but optimistic buffering allows you to determine when and how to lock the resources.

Client server takes the whole thing out of your hands and requires optimistic strategy anyway, unless you use SQLPassthrough to secure table and record locks on teh server.