System. Transactions. isolationlevel defines an enumeration of transaction isolation levels. The explanation in msdn is too simple. Here I paste a copy of the explanation from 1 werwerfer's blog, which should be very clear:
1. readuncommitted-this is, essential, no isolation. anyone can read the data placed in a table or updated immediately after the SQL statement causes the change-No commit is required. this cocould lead to a process having out-of-date data: It may be using a version of the data that was then rolled back out of the table!
2. readcommitted-this is slightly more isolated. in this case, a transaction can only read data from the table that has already been committed. when a transaction wants to update data, it acquires a shared lock on that data and (if successful getting the lock) updates the data. transactions outside of that transaction cannot update the data in that table until the locking transaction commits. this is only slightly more isolated, however: a SQL statement executed twice within a transaction cocould return a different result-set if a second transaction changes and commits the data the SQL statement executes on between the two statements. this is the default isolation level for sqltransaction.
3. repeatableread-slowly getting more isolated. in this case, a shared lock is applied on all data queried within a transaction. this means that no other transaction can alter the data used in your transaction. this prevents the case where data you had queried once changes on subsequent queries. it does not, though, prevent the case where rows are added to the table that may be returned in subsequent queries.
4. serializable-locks are placed on ranges of the tables you are using, preventing other users from changing your data or adding new rows underneath you. this is the most isolated isolation level, but it does come with the drawback of locking more data than your transaction may strictly need.
5. Snapshot isolation (which is supported by SQL server2005 ?). In Snapshot isolation, rows are versioned once they are accessed in a transaction. this essential means that once a transaction accesses a set of values, they are guaranteed to remain the same until you commit or rollback the transaction. other transactions starting in the middle of the first will get a 'copy' of the original database to operate on. before any transaction commits, though, SQL Server will test to ensure that the original data they were operating on is the same as the current data in the database. if this is the case, the transaction will commit. otherwise, the transaction will be rolled back and the user will have to try the batch once again.
However, when I use the followingCodeWhen verifying the readuncommited isolation level, it is found that when the transaction is not completed, uncommitted data is still not accessible. So let's take a look at it and see if there is a problem with my operation steps.
The code snippet is as follows:
1 Transactionscospontion scospontion = Transactionscospontion. required;
2 Transactionoptions options = New Transactionoptions ();
3 Options. Timeout = New Timespan ( 0 , 0 , 30 , 0 , 0 );
4 Options. isolationlevel = System. Transactions. isolationlevel. readuncommitted;
5 Using (Transactionscope scope Scope = New Transactionscope (scoexception, options ))
6 {
7 Createlibsheetlogic. addnewsheet (convert. toint32 (vendeeid), sheetid, This . Memberid );
8 Foreach (Datarow mdbrow In Table. Rows)
9 {
10 Undealedvenderlogic. addnewundealedvender (mdbrow );
11 Int Newundealedvenderid = Gea52sqlexe. getindentity ( " Undealedvender " );
12 Undealedoperatorlogic. addnewoperators (mdbrow, newundealedvenderid );
13 Undealedvenderrelationlogic. addanrelation (newundealedvenderid, sheetid, mdbrow );
14 }
15
16 Scope. Complete ();
17 }
In single-step debugging, the seventh line of code adds a new record to the createlibsheet table. before the execution of the seventh line is complete, execute the new record in the query analyzer.
Select * From createlibsheet can read data. However, once uncommitted new records are added, you can only wait for them to run the same query statement in the query analyzer. As described in the definition of readuncommitted, uncommitted records cannot be retrieved.
I don't know what's going on?