对.net事务隔离级别(IsolationLevel)的一个疑问

System.Transactions.IsolationLevel定义了一个对于事务隔离级别的枚举。MSDN里面的解释过于简单，这里粘贴一段从1werwerfer 的博客里拷来的解释，说得应该是非常清楚：
1.ReadUncommitted – This is, essentially, 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 could 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 could 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(Sql Server2005才支持？). In snapshot isolation, rows are versioned once they are accessed in a transaction. This essentially 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.

但是，当我用如下代码去做验证ReadUncommited隔离级别验证的时候，发现在事务没有完成的时候，未提交数据依然不能被访问。所以提出来请大家参详一下，看看是不是我的操作步骤有问题。
代码段如下：

 1TransactionScopeOption scopeOption = TransactionScopeOption.Required;
 2TransactionOptions options = new TransactionOptions();
 3options.Timeout = new TimeSpan(0, 0, 30, 0, 0);
 4options.IsolationLevel = System.Transactions.IsolationLevel.ReadUncommitted;
 5using (TransactionScope scope = new TransactionScope(scopeOption, 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} 

我采用单步调试，代码的第七行会向CreateLibSheet表加入新记录，在第七行执行完毕之前，在查询分析器里执行
select * from CreateLibSheet 是可以读取到数据的。但一旦未提交的新记录被加入，后面再在查询分析器里运行同样的查询语句就只能等待了，并不能像ReadUncommitted 的定义里所说的，取出未提交记录。

不知是怎么回事？