In my last post , I explained that SQL Server holds read committed locks until the end of an update statement (instead of releasing the locks as soon as each row is released) if there is a blocking operator between the scan or seek of the rows to be updated...

Let's try an experiment. Begin by creating the following simple schema: create table t1 (a int, b int) create clustered index t1a on t1(a) insert t1 values (1, 1) insert t1 values (2, 2) insert t1 values (3, 3) create table t2 (a int) insert...

Both the serializable and snapshot isolation levels provide a read consistent view of the database to all transactions. In either of these isolation levels, a transaction can only read data that has been committed. Moreover, a transaction can read the...

In my last two posts, I showed how queries running at read committed isolation level may generate unexpected results in the presence of concurrent updates. Many but not all of these results can be avoided by running at repeatable read isolation level...

Last week I looked at how concurrent updates may cause a scan running at read committed isolation level to return the same row multiple times or to miss a row entirely. This week I'm going to take a look at how concurrent updates may affect slightly more...