>Mind giving me a quick code review to make sure I grasped all the important concepts?
>
>

>SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;
>
>BEGIN TRANSACTION GetNewLead;
>
>DECLARE @LeadID int =
>	(
>		SELECT TOP 1
>			ID
>		FROM
>			Leads
>		WHERE
>			Processor_Id IS NULL
>		ORDER BY
>			EnteredOn
>	);
>
>UPDATE
>	Leads
>SET
>	Processor_Id = 1
>WHERE
>	ID = @LeadID;
>
>SELECT @LeadID;
>
>COMMIT TRANSACTION GetNewLead;
>
>SET TRANSACTION ISOLATION LEVEL READ COMMITTED;
>

Hi Mike, sorry about the late reply, I read the messages but I did not have time to reply, too many problems at work...

Anyways, your code looks good to me, of course the ultimate proof are your tests, does it run as expected? My experience with this was good, what I did for testing was to run 4 instances of my dialers (limited only by the number of lines in the telephony card) then I simultaneously created many requests and I saw how each dialer would grab one request from the queue, dial-out, play the file on the PA system, hang-up and then pick-up the next one, none of the dialers grabbed an already taken request and none of the dialers got in a deadlock. Now in production it is very frequent (almost always) that the requests come in pairs (two records added to the queue simultaneously, as messages needs to be played in the Stations and Trains PAs that have different lines), and then repeated for a period (normally every 2.5 minutes for 2 hours), and everything works fine, just like the test.