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
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
lockedbit column to the table in question along with alocked_byvarchar column to keep track of who has the row locked.The first user should
UPDATEthe row to indicate that the row is locked and who has it locked: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
SELECTto return the data and ensure that they did really manage to lock the row.