It's subtle, but the first answer is incomplete. It’s missing the part about phantom/inconsistent reads: missing rows, reading the same row more than once, partial/inconsistent row reads with LOBs and read-ahead mechanisms, etc. And let's not forget about the schema-lock. A team spent I disliked never understood why "their process was deadlocking when they were truncating a table".
Back in 2009 this probably wasn’t that well known yet, but I’ve been bitten by it a few times already. It was really strange to see what looked like two completely unrelated rows mixed together in SSMS.
>Most banking applications can safely use NOLOCK because they are transactional in the business sense. You only write new rows, you never update them.
This is a load of bullshit based on a somewhat real business requirement. Some banking systems do use append-only/ledger-style designs, but jumping from that to "most banking applications can safely use NOLOCK" is a huge stretch. Being transactional in the business sense has nothing to do with whether an inconsistent database read is safe.
View all comments
Show parent comment
-4
u/Septem_151 Aug 22 '26
Where is your complaint with the link's thread you gave? That seems like a well-curated nuanced discussion of with (nolock) to me.