成员函数Save(string rollbackstring) 在事务中创建保存点（它可用于回滚事务的一部分），并指定保存点名称。如 SqlTransaction.save("NoUpdate") // 创建回滚点。 SqlTransaction.Rollback("NoUpdate")//回滚到回滚点
{
SqlConnection myConnection = new SqlConnection(myConnString);
myConnection.Open();
SqlCommand myCommand = new SqlCommand();
SqlTransaction myTrans;
// Start a local transaction
myTrans = myConnection. BeginTransaction(IsolationLevel.ReadCommitted,"SampleTransaction");
// Must assign both transaction object and connection
// to Command object for a pending local transaction
myCommand.Connection = myConnection;
myCommand.Transaction = myTrans;
try
{
myCommand.CommandText = "Insert into Region (RegionID, RegionDescription)
VALUES (100, 'Description')";
myCommand.ExecuteNonQuery();
myCommand.CommandText = "Insert into Region (RegionID, RegionDescription)
VALUES (101, 'Description')";
myCommand.ExecuteNonQuery();
myTrans.Commit();
Console.WriteLine("Both records are written to database.");
}
catch(Exception e)
{
myTrans.Rollback("SampleTransaction");
Console.WriteLine(e.ToString());
Console.WriteLine("Neither record was written to database.");
}
finally
{
myConnection.Close();
}
}
事务处理可以确保除非事务性单元内的所有操作都成功完成，否则不会永久更新面向数据的资源。通过将一组相关操作组合为一个要么全部成功要么全部失败的单元，可以简化错误恢复并使应用程序更加可靠。一个逻辑工作单元要成为事务，必须满足所谓的ACID(原子性、一致性、隔离性和持久性)属性：
原子性
事务必须是原子工作单元；对于其数据修改，要么全都执行，要么全都不执行。通常，与某个事务关联的操作具有共同的目标，并且是相互依赖的。如果系统只执行这些操作的一个子集，则可能会破坏事务的总体目标。原子性消除了系统处理操作子集的可能性。
一致性
事务在完成时，必须使所有的数据都保持一致状态。在相关数据库中，所有规则都必须应用于事务的修改，以保持所有数据的完整性。事务结束时，所有的内部数据结构（如 B 树索引或双向链表）都必须是正确的。某些维护一致性的责任由应用程序开发人员承担，他们必须确保应用程序已强制所有已知的完整性约束。例如，当开发用于转帐的应用程序时，应避免在转帐过程中任意移动小数点。
隔离性
由并发事务所作的修改必须与任何其它并发事务所作的修改隔离。事务查看数据时数据所处的状态，要么是另一并发事务修改它之前的状态，要么是另一事务修改它之后的状态，事务不会查看中间状态的数据。这称为可串行性，因为它能够重新装载起始数据，并且重播一系列事务，以使数据结束时的状态与原始事务执行的状态相同。当事务可序列化时将获得最高的隔离级别。在此级别上，从一组可并行执行的事务获得的结果与通过连续运行每个事务所获得的结果相同。由于高度隔离会限制可并行执行的事务数，所以一些应用程序降低隔离级别以换取更大的吞吐量。
持久性
事务完成之后，它对于系统的影响是永久性的。该修改即使出现致命的系统故障也将一直保持。
DBMS的责任和我们的任务
企业级的数据库管理系统（DBMS）都有责任提供一种保证事务的物理完整性的机制。就常用的SQL Server2000系统而言，它具备锁定设备隔离事务、记录设备保证事务持久性等机制。因此，我们不必关心数据库事务的物理完整性，而应该关注在什么情况下使用数据库事务、事务对性能的影响，如何使用事务等等。
企业级的数据库每一秒钟都可能应付成千上万的并发访问，因而带来了并发控制的问题。由数据库理论可知，由于并发访问，在不可预料的时刻可能引发如下几个可以预料的问题：
脏读：包含未提交数据的读取。例如，事务1 更改了某行。事务2 在事务1 提交更改之前读取已更改的行。如果事务1 回滚更改，则事务2 便读取了逻辑上从未存在过的行。
不可重复读取：当某个事务不止一次读取同一行，并且一个单独的事务在两次（或多次）读取之间修改该行时，因为在同一个事务内的多次读取之间修改了该行，所以每次读取都生成不同值，从而引发不一致问题。
幻象：通过一个任务，在以前由另一个尚未提交其事务的任务读取的行的范围中插入新行或删除现有行。带有未提交事务的任务由于该范围中行数的更改而无法重复其原始读取。
如你所想，这些情况发生的根本原因都是因为在并发访问的时候，没有一个机制避免交叉存取所造成的。而 隔离级别的设置，正是为了避免这些情况的发生。事务准备接受不一致数据的级别称为 隔离级别。 隔离级别是一个事务必须与其它事务进行隔离的程度。较低的 隔离级别可以增加并发，但代价是降低数据的正确性。相反，较高的 隔离级别可以确保数据的正确性，但可能对并发产生负面影响。
根据 隔离级别的不同，DBMS为并行访问提供不同的互斥保证。在SQL Server数据库中，提供四种 隔离级别：未提交读、提交读、可重复读、可串行读。这四种 隔离级别可以不同程度地保证并发的数据完整性：
| 隔离级别 | 脏 读 | 不可重复读取 | 幻 像 |
| 未提交读 | 是 | 是 | 是 |
| 提交读 | 否 | 是 | 是 |
| 可重复读 | 否 | 否 | 是 |
| 可串行读 | 否 | 否 | 否 |
可以看出，“可串行读”提供了*别的隔离，这时并发事务的执行结果将与串行执行的完全一致。如前所述，*别的隔离也就意味着最低程度的并发，因此，在此隔离级别下，数据库的服务效率事实上是比较低的。尽管可串行性对于事务确保数据库中的数据在所有时间内的正确性相当重要，然而许多事务并不总是要求完全的隔离。例如，多个作者工作于同一本书的不同章节。新章节可以在任意时候提交到项目中。但是，对于已经编辑过的章节，没有编辑人员的批准，作者不能对此章节进行任何更改。这样，尽管有未编辑的新章节，但编辑人员仍可以确保在任意时间该书籍项目的正确性。编辑人员可以查看以前编辑的章节以及最近提交的章节。这样，其它的几种隔离级别也有其存在的意义。
在.net框架中，事务的隔离级别是由枚举System.Data.IsolationLevel所定义的：
| [Flags] [Serializable] public enum IsolationLevel |
其成员及相应的含义如下：
| 成 员 | 含 义 |
| Chaos | 无法改写隔离级别更高的事务中的挂起的更改。 |
| ReadCommitted | 在正在读取数据时保持共享锁，以避免脏读，但是在事务结束之前可以更改数据，从而导致不可重复的读取或幻像数据。 |
| ReadUncommitted | 可以进行脏读，意思是说，不发布共享锁，也不接受独占锁。 |
| RepeatableRead | 在查询中使用的所有数据上放置锁，以防止其他用户更新这些数据。防止不可重复的读取，但是仍可以有幻像行。 |
| Serializable | 在DataSet上放置范围锁，以防止在事务完成之前由其他用户更新行或向数据集中插入行。 |
| Unspecified | 正在使用与指定隔离级别不同的隔离级别，但是无法确定该级别。 |
显而意见，数据库的四个隔离级别在这里都有映射。
默认的情况下，SQL Server使用ReadCommitted(提交读)隔离级别。
关于隔离级别的最后一点就是如果你在事务执行的过程中改变了隔离级别，那么后面的命名都在最新的隔离级别下执行——隔离级别的改变是立即生效的。有了这一点，你可以在你的事务中更灵活地使用隔离级别从而达到更高的效率和并发安全性。