GSquared (11/7/2012)

---

The first one will do what you're looking for. Isolation levels are set for the connection, not for the object.

HOWEVER, I have to warn you that setting isolation to read uncommitted is almost always a really, really, really bad idea. There are very, very few situations where it is the correct thing to do, and almost none of them involve repeat-run code like a stored procedure.

What read uncommitted (and the query hint NoLock) do, is allow you to read wrong data from the tables involved. Data that has changed, data that is being deleted, even (in some case) the same data more than one time. The only time to ever use any of these things is when the accuracy of the data doesn't matter at all.

Make sure the business units or customers who will be using the application this stored procedure will be part of, understand that the data it presents to them may be wrong, potentially by an arbitrarily large amount. If they are fine with that, go ahead and use Read Uncommitted. If they ask you if you're crazy when you tell them you want the database to give them the wrong data, or make threatening noises about the potentially short future of your employment, tell them you were just joking and hope that they buy it.

It's your decision, of course. You know what's needed by your business users/customers better than I do, of course. But do take the potentially huge data flaws it will generate into account.