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

Hi, Mike

Hugo gave you a great example - don't want to steal his thunder, but here's the Reader's digest version. (Hugo, that was a great example)

When you specify REPEATABLE READ inside a transaction, that means that SQL Server places a shared lock on any rows you query during the procedure/transaction - thereby preventing anyone from updating the row until the proc/transaction is finished. (Note: it won't prevent someone from simply reading, but would prevent someone from writing)

Unlike the default READ COMMITTED, which only would only hold the shared lock for the duration of the single SELECT query, a REPEATABLE READ holds the shared lock longer, until the transaction is finished. (A repeatable read is like an extended READ COMMITTED)

The reason they call it REPEATABLE READ is that, in your proc, if you read a row at the beginning and then read the same row at the end, you are assured that no one else could modify it while your procedure/txaction is running.

So in your example, you're querying for a single LEAD, and then updating it. There is no chance that another person could come along and update the row while your proc is running. For a scenario where you need to read a row and then update it and change something immediately, what he sent you should be a good solution.