Don't make life more complicated than it needs to be. I would not bother trying to issue locks in SQL Server. It consumes too many resources and will cause deadlocking grief. Besides, there should be no need for locks, just use transactions when updating records.

If you want to be sure a record selected for editing has not been changed before you make changes, add timestamp fields to all records and set remote views to use timestamps. A timestamp is not really a timestamp, it's more like a GUID that changes each time a record is updated, so an update will fail if the timestamp changes. But you really have to think this through.

SQL Server is by default I suppose, multi-user.

Personally, and I'm not alone in this I know. I just ignore multi-user contention issues. If multiple tables are being updated I use transactions to make sure all or none of the data in a transaction is updated. That's it. Last person to touch a record wins. In 99% of the cases this works fine. The only time you need to code your updates carefully is in an inventory type app where you select an item that says 25 are left, you sell 25 but in the meantime, before you update, someone else sold 10. In this kind of a situation, a timestamp field works well. Otherwise, provide a good reason to require record locks or special processing. I don't think it's necessary.

You can code for the exceptions. Pretty much all my projects have been SQL Server over the last 4 years and this model has worked just fine.


>Hello,
>I want to implement a multiuser enviroment using SQL Server.
>I want to use locks on the server-side but i dont know how to implement it.
>
>Is there any article explaining how to implement a multiuser enviroment based on server-side?
>
>I also want to know, when should i lock the records an when to unlock them.
>I know that i got a lot of issues, but if anyone can help me out, ill apreciate.
>
>Thanks all for your time
>Ricardo Martins
>IMS USA