SQL Server 2008 Express locking

Question

OK so I have read a fair amount about SQL Server's locking stuff, but I'm struggling to understand it all.

What I want to achieve is thus:

I need to be able to lock a row when user A SELECTs it

If user B then tries to SELECT it, my winforms .net app needs to set all the controls on the relevant form to be disabled, so the user can't try and update. Also it would be nice if I could throw up a messagebox for user B, stating that user A is the person that is using that row.

So basically User B needs to be able to SELECT the data, but when they do so, they should also get a) whether the record is locked and b) who has it locked.

I know people are gonna say I should just let SQL Server deal with the locking, but I need User B to know that the record is in use as soon as they SELECT it, rather than finding out when they UPDATE - by which time they may have entered data into the form, giving me inconsistency.

Also any locks need to allow SELECTs to still happen - so when user B does his SELECT, rather than just being thrown an exception and receiving no/incomplete data, he should still get the data, and be able to view it, but just not be able to update it.

I'm guessing this is pretty basic stuff, but there's so much terminology involved with SQL Server's locking that I'm not familiar with that it makes reading about it pretty difficult at the moment.

Thanks

Answer 1

To create this type of 'application lock', you may want to use a table called Locks and insert key, userid, and table names into it.

When your select comes along, join into the Locks table and use the presence of this value to indicate the record is locked.

I would also recommend adding a 'RowVersion' column to your table you wish to protect. This field will assist in identifying if you are updating or querying a row that has changed since you last selected it.

Answer 2

This isn't really what SQL Server locking is for - ideally you should only be keeping a transaction (and therefore a lock) open for the absolute minimum needed to complete an atomic operation against that database - you certainly shouldn't be holding locks while waiting for user input.

You would be better served keeping track of these sorts of locks yourself by (for example) adding a locked bit column to the table in question along with a locked_by varchar column to keep track of who has the row locked.

The first user should UPDATE the row to indicate that the row is locked and who has it locked:

UPDATE MyTable 
SET `locked`  = 1
AND `locked_by` = @me
WHERE `locked` = 0

The locked = 0 check is there to protect against potential race conditions and make sure that you don't update a record that someone else has already locked.

This first user then does a SELECT to return the data and ensure that they did really manage to lock the row.