>Jim,
>I think you've short-changed Nelson here. I would try adjusting your reply myself, but I don't know enough to competently do so.
>I think that such locking *can* be done and is regularly done within SQL (server) transactions.
>I think that locking might well be done on a 'page' basis, but that is really irelevant here because the intention of the locking is to temporarily isolate the record in question. It may just so happen that a 'page' is the granularity used by a specific SQL product.
> SNIP <<<

Unless your app has a very small number of users, who are unlikely to be accessing the app at the same time, it would be a very bad idea to lock a page while the user is updating information on a screen (the old-fashioned Pessimistic locking).

This is bad for a client-server app, because it will lock users out of otherwise-unrelated rows in the table. It can be catastrophic for an n-tier app working under COM+ with an STA model (or even MTA, but especially STA) because in addition to locking users out of rows, you will hold ADO connections, lock threads, and thereby affect even those processes that do not deal directly with data.

I don't think Jim short-changed him at all. In fact, I would have been more emphatic. I'd argue that designing a c/s app with pessimistic locks is akin to designing, say, a VFP app that will store its data in notepad files rather than dbf's.... it just doesn't make sense, and even if you can do it, you either need to step back and re-think what you are trying to accomplish, or ask yourself if you are working with the right tool for the particular job.

Vin