我正在维护一个ASP/C#程序，该程序使用MS SQL Server 2008 R2来满足其数据库要求。
在正常和完美的日子里，一切都很好。但我们并不生活在一个完美的世界里。
申请（休假、病假、加班、下班等）审批过程最多需要十个单独的数据库连接。该程序连接到数据库，传递一些相关参数，并使用存储过程来完成作业。十倍。
现在，由于整个事情的结构，我无法更改，连接下降，或者哎呀，如果我在VS2005中放置一个调试点并让它在那里挂起足够长的时间，应用程序批准过程将不完整。这些表通常只是连接在一起，因此数据不匹配 - 此处缺少数据，那里的主键更新失败 - 将意味着整行将毫无用处。
现在，我知道我无能为力来防止这种情况 - 毕竟这是一个连接问题。
但是有没有办法最大限度地减少连接滞后/故障？或者一种通知用户该过程出现问题的方法？回滚更改功能（通过程序或 SQL），以便撤消数据库中任何不完整的数据？
谢谢。
但是有没有办法最大限度地减少连接滞后/故障？或者一种方式 通知用户该过程出了问题？一个 回滚更改功能（通过程序或 SQL），以便任何 数据库中不完整的数据将被撤消吗？
正如我们在评论中所讨论的，交易将解决您的许多担忧。
事务包括在数据库中执行的工作单元 管理系统（或类似系统）针对数据库，并处理 以独立于其他交易的连贯可靠的方式。 数据库环境中的事务有两个主要目的：
提供可靠的工作单元，允许从故障中正确恢复，即使在系统的情况下也能保持数据库的一致性 失败，当执行停止（全部或部分）和许多 对数据库的操作仍未完成，状态不明确。
在并发访问数据库的程序之间提供隔离。如果未提供此隔离，则程序的结果 可能是错误的。
源
.Net 中的事务
如您所料，数据库对于为与数据库相关的操作提供事务支持是不可或缺的。但是，从业务层创建事务非常简单，并允许您跨多个数据库调用使用单个事务。
引用我的回答：
我认为从业务层控制事务有几个原因：
-
跨数据存储边界的通信。事务不必针对 RDBMS;它们可以针对各种实体。
-
能够基于业务逻辑回滚/提交事务，而业务逻辑可能不适用于您正在调用的特定存储过程。
-
在单个事务中调用任意一组查询的能力。这也消除了担心事务计数的需要。
-
个人偏好：C# 具有更优雅的事务声明结构：
using块。相比之下，我总是发现存储过程中的事务在跳转到回滚/提交时很麻烦。
交易最容易使用TransactionScope（引用）抽象来声明，这为您完成了艰苦的工作。
using( var ts = new TransactionScope() )
{
// do some work here that may or may not succeed
// if this line is reached, the transaction will commit. If an exception is
// thrown before this line is reached, the transaction will be rolled back.
ts.Complete();
}
由于您刚刚开始处理事务，因此我建议您从 .Net 代码中测试事务。
- 调用执行插入的存储过程。
- 插入后，故意让过程生成任何类型的错误。
- 您可以通过查看 INSERT 是否自动回滚来验证您的实现。
数据库中的事务
当然，您也可以在存储过程（或任何类型的 TSQL 语句）中声明事务。有关更多信息，请参阅此处。
如果使用相同的 SQLConnection 或其他实现 IDbConnection 的连接类型，则可以执行类似于事务作用域的操作，但无需创建事务作用域的安全风险。
在 VB 中：
Using scope as IDbTransaction = mySqlCommand.Connection.BeginTransaction()
If blnEverythingGoesWell Then
scope.Commit()
Else
scope.Rollback()
End If
End Using
如果未指定提交，则默认为回滚事务。