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 N


SNIP
>
>You also need to consider the likelihood that two users will affect the same record at the same time versus consumming system resources for locks all over the place when you will most likely never need them.