提交/回滚后，SQL Server 2008 R2中快照隔离级别中来自ADO.Net的事务未更改为默认隔离级别

Question

I have the following code in C# using ADO.NET for updating data in a SQL Server 2008 R2 database using the SNAPSHOT isolation level. This code is working perfectly. However, if I go to another page in my ASP.Net app after this, where a query runs between this database table joined with another database table on same server, then I get an error that says:

System.Data.SqlClient.SqlException: Snapshot isolation transaction failed accessing database 'Member_Security' because snapshot isolation is not allowed in this database. Use ALTER DATABASE to allow snapshot isolation.

Query that throws an error as pasted above, if it runs after the SNAPSHOT transaction code:

select 
   e.EmpId, e.EmpHours, m.SecurityLevel, m.IsPriveleged 
from 
   Emp e 
inner join 
   Member_Security.dbo.Members m

If I do not run the transaction in code below in SNAPSHOT level, then there is no problem.

Why is this happening and how can I correct it?

I think in this case SNAPSHOT isolation level is not getting reset to what was before this code ran.

Code that runs perfectly:

con = new SqlConnection();
con.ConnectionString = ConfigurationManager.ConnectionStrings["EMP"].ConnectionString;
con.Open();
tran = con.BeginTransaction(IsolationLevel.Snapshot);  
cmd = new SqlCommand();
cmd.CommandTimeout = 0; 
cmd.Connection = con;
cmd.Text = "Update emp set empcomm = 200 where empage > 40;"
cmd.Transaction = tran;

try {
    cmd.ExecuteNonQuery();
    tran.Commit();
}
catch(Exception ex)
{
    try 
    { 
        if(tran != null) 
           tran.rollback();
    } 
    catch{}
}
finally 
{ 
     DAL.ResetTransactionIsolationLevel(); 
} //NEED THIS TO SOLVE THIS PROBLEM

UPDATE 1:

It seems there is a problem when using an isolation level other than the default one from ADO.Net code according to this paragraph taken from following url: Need to explicitly set Isolation Level when using non-default isolation level in ADO.Net code

After a transaction is committed or rolled back, the isolation level of the transaction persists for all subsequent commands that are in autocommit mode (the SQL Server default). This can produce unexpected results, such as an isolation level of REPEATABLE READ persisting and locking other users out of a row. To reset the isolation level to the default (READ COMMITTED), execute the Transact-SQL SET TRANSACTION ISOLATION LEVEL READ COMMITTED statement, or call SqlConnection.BeginTransaction followed immediately by SqlTransaction.Commit. For more information on SQL Server isolation levels, see "Isolation Levels in the Database Engine" in SQL Server Books Online.

UPDATE 2:

The only way I avoided this was to set isolation level to Read Committed after the above transaction was done ie call the method 'ResetTransactionIsolationLevel' in the finally block of above transaction. If I did this then I did not see any problems when executing cross-database queries after the SNAPSHOT isolation level. I added the finally block to show this solution in above code snippet.

 public static void ResetTransactionIsolationLevel()
    {
        SqlCommand cmd = new SqlCommand();
        SqlConnection conn = new SqlConnection(ConfigurationManager.ConnectionStrings["EMP"].ConnectionString);


        try
        {
            cmd.CommandText = "set transaction isolation level read committed";
            cmd.CommandType = CommandType.Text;
            cmd.Connection = conn;
            conn.Open();
            cmd.ExecuteNonQuery();
            conn.Close();
        }
        finally
        {
            cmd.Dispose();
            conn.Close();
            conn.Dispose();
        }
    }

Answer 1

From here: http://msdn.microsoft.com/en-us/library/tcbchxcb(v=vs.110).aspx Snapshot isolation must be enabled by setting the ALLOW_SNAPSHOT_ISOLATION ON database option before it is used in transactions.

Run this on your database:

ALTER DATABASE MyDatabase
SET ALLOW_SNAPSHOT_ISOLATION ON

UPDATE If you want to Read Committed SNAPSHOT in subsequent transactions without specifying it implicitly, also run:

ALTER DATABASE MyDatabase
SET READ_COMMITTED_SNAPSHOT ON

Note that this is NOT read committed, and all data is still going through tempdb, so you really need to consider the capacity for your db and application.