>>Hi guys!
>>
>>Does any body know where may I find an article on row level locking under Client/Server Enviorments?
>>
>>Maybe with a sample of a case where user A cannot access record Number 31 because user B is currently using it with read/write intentions.
>>
>>Thanks in advance.
>>
>>NJM
>
>Nelson,
>
>The short answer is that you can not do it. Many C/S backends don't provide for record locking, they use pages instead. Plus the whole idea of a database server is contrary to the pessimistic approach to locking. You need to deal with the possibility that your user's data cannot be saved when you try to save it and recover from that situation.

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.
There are settings available in most SQL products to control the kind/longevity of locks applied and they can vary by table or procedure or other factors. Yes, these may be set at the system level and be unreacheable by programming, but they do exist and can be varied by authorized personnel.

I know that it is technically feasible to write routines that identify the fields in update conflicts and resolve them automatically (where possible) or through dialog with the SAVEr. But there are cases where such a facility is too dangerous and so impractical.

I would also be interested to learn if MSDE, installed on (say) a Win98SE system and with VFP and used by a VFP application (i.e. no other SQL Server components installed in the shop) could be 'managed' sufficiently to make the various settings possible to control aspects of SQL Server that are possible with the full product.

Jim