2 added 12 characters in body
source | link

The hint NOLOCK is equivalent to the transaction isolation level READ UNCOMMITTED, just restricted to the scope of one querytable access method.  

What RU does that makes the non-committed appear on your resultset? Hmm, actually is a question of "what it not does. I'll explain below.

Well (this is a gross simplification, I know) MSSQL (in its' default behavior) is a lock engine - which means that it uses lock to read/write data on a consistent manner. In this oversimplified explanation, MSSQL uses two kinds of locks: shared lock and exclusive lock.

An shared(S) lock is a lock that allow an resource (which can be a row, page of rows or even an entire table) to be read - but not allows an write to it. So if transaction T1 puts a S lock on R1 row, all transactions that tries to read R1 will get that read, but while the S lock is alive nobody can write to R1.

An exclusive(X) lock is the counterpart of the shared lock. It allows exclusive access to a resource - no other transaction can read or write except the one that got the X lock. In the above example, if T1 got not an S lock but an X lock on R1, no one except T1 can read or write it.

That's the teory. The isolation levels honor the locks, and respect their prevalence and characteristics. All, except READ UNCOMMITTED. It simple gives a * (put your bad mouth word of your preference here) to the locks regarding the reading - you still cannot update the row another transaction got an X lock. It simply says: "I'll read everything that's relevant to the query plan - disregard what locks are on it." And do it.

The hint NOLOCK is equivalent to the transaction isolation level READ UNCOMMITTED, just restricted to the scope of one query.  

What RU does that makes the non-committed appear on your resultset? Hmm, actually is a question of "what it not does. I'll explain below.

Well (this is a gross simplification, I know) MSSQL (in its' default behavior) is a lock engine - which means that it uses lock to read/write data on a consistent manner. In this oversimplified explanation, MSSQL uses two kinds of locks: shared lock and exclusive lock.

An shared(S) lock is a lock that allow an resource (which can be a row, page of rows or even an entire table) to be read - but not allows an write to it. So if transaction T1 puts a S lock on R1 row, all transactions that tries to read R1 will get that read, but while the S lock is alive nobody can write to R1.

An exclusive(X) lock is the counterpart of the shared lock. It allows exclusive access to a resource - no other transaction can read or write except the one that got the X lock. In the above example, if T1 got not an S lock but an X lock on R1, no one except T1 can read or write it.

That's the teory. The isolation levels honor the locks, and respect their prevalence and characteristics. All, except READ UNCOMMITTED. It simple gives a * (put your bad mouth word of your preference here) to the locks regarding the reading - you still cannot update the row another transaction got an X lock. It simply says: "I'll read everything that's relevant to the query plan - disregard what locks are on it." And do it.

The hint NOLOCK is equivalent to the transaction isolation level READ UNCOMMITTED, just restricted to the scope of one table access method.

What RU does that makes the non-committed appear on your resultset? Hmm, actually is a question of "what it not does. I'll explain below.

Well (this is a gross simplification, I know) MSSQL (in its' default behavior) is a lock engine - which means that it uses lock to read/write data on a consistent manner. In this oversimplified explanation, MSSQL uses two kinds of locks: shared lock and exclusive lock.

An shared(S) lock is a lock that allow an resource (which can be a row, page of rows or even an entire table) to be read - but not allows an write to it. So if transaction T1 puts a S lock on R1 row, all transactions that tries to read R1 will get that read, but while the S lock is alive nobody can write to R1.

An exclusive(X) lock is the counterpart of the shared lock. It allows exclusive access to a resource - no other transaction can read or write except the one that got the X lock. In the above example, if T1 got not an S lock but an X lock on R1, no one except T1 can read or write it.

That's the teory. The isolation levels honor the locks, and respect their prevalence and characteristics. All, except READ UNCOMMITTED. It simple gives a * (put your bad mouth word of your preference here) to the locks regarding the reading - you still cannot update the row another transaction got an X lock. It simply says: "I'll read everything that's relevant to the query plan - disregard what locks are on it." And do it.

1
source | link

The hint NOLOCK is equivalent to the transaction isolation level READ UNCOMMITTED, just restricted to the scope of one query.

What RU does that makes the non-committed appear on your resultset? Hmm, actually is a question of "what it not does. I'll explain below.

Well (this is a gross simplification, I know) MSSQL (in its' default behavior) is a lock engine - which means that it uses lock to read/write data on a consistent manner. In this oversimplified explanation, MSSQL uses two kinds of locks: shared lock and exclusive lock.

An shared(S) lock is a lock that allow an resource (which can be a row, page of rows or even an entire table) to be read - but not allows an write to it. So if transaction T1 puts a S lock on R1 row, all transactions that tries to read R1 will get that read, but while the S lock is alive nobody can write to R1.

An exclusive(X) lock is the counterpart of the shared lock. It allows exclusive access to a resource - no other transaction can read or write except the one that got the X lock. In the above example, if T1 got not an S lock but an X lock on R1, no one except T1 can read or write it.

That's the teory. The isolation levels honor the locks, and respect their prevalence and characteristics. All, except READ UNCOMMITTED. It simple gives a * (put your bad mouth word of your preference here) to the locks regarding the reading - you still cannot update the row another transaction got an X lock. It simply says: "I'll read everything that's relevant to the query plan - disregard what locks are on it." And do it.