If your admin suggests that you should use NOLOCK in your queries, your admin should get the sack! NOLOCK very rarely has any place in application code. With NOLOCK, this can happen:
- You are reading uncommitted and inconsistent data. Take for instance a transfer from one account to another, and you are computing the sum for all accounts, and you read as the withdrawal has been booked, but not the deposit. You get the wrong result!
- You may fail to read committed data, because it was moved due to page splits. When you have NOLOCK/READUNCOMMITTED, SQL Server scans tables in a way where such misses can happens.
- For the same reason, you may read the same data twice.
- The query can die with error 601.
NOLOCK is great for diagnostic queries where you just want to know how far an large transaction has progressed. But application code? No.
Snapshot transactions, on the other hand, gives you very consistent result. Because of the semantics of snapshot isolation, the result may be outdated, which can be a problem for validations. Also, with snapshot transactions, you are not very prone to cause deadlocks. Long-running snapshot transactions can result in the version store in tempdb to grow, though.
So either you are admin is completely confused, or your are describing your situation inaccurately.