SQL Server - inconsistent behavior when reading uncommitted changes of the same transaction

Question

Working with SQL server with isolation level "read committed snapshot", we routinely write data to the database and read it further on in the context of the same transaction. Usually when reading from the database we see our own uncommitted changes but only committed changes made by others. We assumed that this is the expected behavior .

We now found that in some relatively rare cases we don't see the values we've written - only previously committed values.

Any ideas what might be causing the inconsistency?

Answer 1

Ther are some good articles on what could go wrong. Perhaps they might help

Craig Freedman, Serializable vs. Snapshot Isolation Level The black/white marble analogy

Hugo Kornelis, 4 articles "Snapshot isolation: A threat for integrity": DRI/FKs silently changing to different isolation levels

Answer 2

It turns out that this is a known inconsistency in SQL Server: when you read from the database you usually see your own transaction's uncommitted changes (in all isolation levels), but this is not always guaranteed. The work around in my case was to use with (readuncommitted), trusting an application-level locking mechanism that prevents concurrent modifications of the same data.

I received the same answer from two independent database experts. Unfortunately, I didn't find any written reference to the issue.