0

If my connection allows dirty reads, is it possible that I would get inconsistent results from multiple fields of the same row? Example:

Connection 1:

Update table1 set col1 = 1, col2 = 1 where primarykey = 1
Update table2 set col1 = 2, col2 = 2 where primarykey = 1

Connection 2:

select col1, col2 from table1 where primarykey = 1

is it possible that connection 2 could see non-equal values for col1 and col2? e.g., col1=1 and col2=2 , or, col1=2 and col2=1

Elroy Flynn
  • 3,032
  • 1
  • 24
  • 33
  • 1
    Yes it is very possible. That is the crux of read uncommitted right? It may or may not see the new value from your update because you are saying you don't want the select statement to wait. You can get missing and/or duplicate rows and a whole host of other bizarre things. http://blogs.sqlsentry.com/aaronbertrand/bad-habits-nolock-everywhere/ – Sean Lange Apr 20 '17 at 18:54
  • I wonder if you read the example carefully. Of course with read uncommitted you could get rows with uncommitted values, but I think it would be somewhat surprising to receive a single row in which one field reflects an uncommitted update and another field does not reflect the new value _from the same update._ – Elroy Flynn Apr 21 '17 at 13:53
  • As far as I know you will not get a single row mixed across values like you are describing. But since you are concerned about accuracy of your results then you shouldn't be using read uncommitted. It is far more than just dirty reads. – Sean Lange Apr 21 '17 at 14:09

0 Answers0