Vin,
SNIp
>
>Wow. Seven question marks. I will try to provide a suitable answer! <s> That statement was one side of a two-sided argument I presented, wasn't it? I said that if one is trying to use a tool in a way that is waaaaaay out of the norm, he/she should step back and consider what he or she is trying to accomplish, or whether they're using the right tool for the job.

I'm fond of question marks and exclamation points < s >.
I guess it's this "norm" that I'm challenging a bit... my view is that, as happens with so many other things in our business, a norm that is applicable in, say, a web environment gets "extended" to all situations in all environments. It's far easier to have a "one rule fits all" on an issue rather than to have a few rules, or so it seems. Like 'all PKs are to be surrogate keys' for example.
Now MS is clearly pushing the "disconnected" (my term) model for data access and update and so that no doubt contributes to this "norm". But that doesn't mean that it is applicable in every case and I believe that if pressed MS would agree to that.

>
>If there is a real business need for a database level row lock, there are all sorts of designs and languages that are not appropriate. I stand by that assertion.

A reasonable assertion, but I understood your original statement in the context of VFP and SQL Server and I contend that those are reasonable tools for a job as described.

JimN

>
SNIP