Hello
Ok, you might be confused: READ_COMMITED_SNAPSHOT and the transaction isolation level SNAPSHOT are different.
When you set a database to READ_COMMITED_SNAPSHOT your database will add 16 bytes to each row in the table for version storing. So whenever modifications to the data happen
the readers are able to access a version of the row. This is statement level meaning the phantom rows and repeatable reads within the default transaction level (now
READ_COMMITTED_SNAPSHOT) are possible.
SET TRANSACTION ISOLATION SNAPSHOT is different. There is no version store initially, it is on request. So modifications will create the versioning so readers
will not be blocked. This transaction level (similar to SERIALIZABLE without the blocking) phantom rows and non-repeatable reads are not possible. SNAPSHOT isolation is
transaction level. With this transaction level you can run into problems when you have two (or more) writers, when the first transaction one creates a row version the next transaction
comes along it also uses the version store. When the first transaction tries to commit it's fine as the its version is up to date but as the second user/transaction goes to commit its transaction details (from the version it read) are now out of date.
The second transaction won't commit as it's not consistent.
So what your problem is you are using both methods but when you are setting the transaction isolation level (from your clients) to SNAPSHOT the READ_COMMITED_SNAPSHOT is ignored.
You need to ask whether your procedures require the snapshot equivalent of COMMITED or SERIALIZABLE?
Hope this helps
Rob