MSSQL har inbyggda låsningsfunktioner ja. Jag är inte jätteinsatt i det hela, men här är ett förslag till lösning om du inte redan löst det.
Tänk exempelvis att vi har en tabell med namnet "lock", innehållande id (int, primary key, identity), fn (char), en (char).
Två exempelrader:
1 Sven Svensson
2 Jan Jansson
Skapa två anslutningar i exempelvis Query Analyzer om du har den installerad. Klistra in nedanstående i respektive fönster.
Fönster 1
BEGIN TRANSACTION
SET TRANSACTION ISOLATION LEVEL Repeatable read
SELECT * FROM lock WHERE id = 1
Fönster 2
SET LOCK_TIMEOUT 5000
UPDATE lock SET fn = 'David' WHERE id = 1
Kör koden i fönster 1. Den påbörjar en transaktion, sätter isolation level till Repeatable read (Share locks samt Exclusive locks hålls under hela transaktionen), och sedan gör den en enkel select och begär post 1. Observera att transaktionen inte avslutas ännu.
Över till fönster 2. Kör koden. Den ska vänta maximalt fem sekunder (standard är obegränsat) innan den ger upp ifall den stöter på ett lås. Den försöker nu uppdatera post 1 genom att ändra förnamnet från Sven till David. Men eftersom fönster 1 har en pågående transaktion och en strikt isolation level så är den posten låst och det kommer misslyckas, och efter fem sekunder ge ett felmeddelande. Men testa att byta ut id 1 mot 2 istället. Den posten är inte låst och kan därmed ändras eller raderas.
I fönster 1 avslutar du sedan transaktionen med antingen COMMIT TRANSACTION eller ROLLBACK TRANSACTION. Transaktionen är därmed genomförd eller "tillbakarullad" och post 1 är "upplåst".
Med andra ord: Din webbsida/program/whatever startar en transaktion, sätter lås och hämtar en/flera poster. När personen är klar och ändringarna har gjorts skickas kommandot COMMIT TRANSACTION.
Det som då återstår att fundera på är hur länge MSSQL håller ett lås (om du hypotetiskt aldrig skickar COMMIT TRANSACTION) och hur man eventuellt kan släppa låset efter en viss tidsperiod. Detta har jag dock inget svar på.
Hoppas mitt svammel kan hjälpa lite iaf. Det finns kanske finare lösningar, jag vet inte...
/David