2

我使用的是 .NET 2.0 和 SQL Server 2005。由于历史原因，应用程序代码使用 SQLTransaction，但一些存储过程也使用 T-SQL begin/commit/rollback tran 语句。这个想法是 DBTransaction 可以跨越许多存储过程，每个单独的 sproc 控制在其范围内发生的事情 - 实际上这些是嵌套事务。

代码的旧行为是，如果任何存储过程失败，应用程序逻辑也会导致外部 SQLTransaction 也回滚。但是现在我们想改变逻辑，这样，即使出现故障，外部事务也应该继续按顺序执行剩余的存储过程，最后，由于我们知道有故障，我们回滚整个 SQLTransaction。

问题在于，至少就目前的编码而言，如果任何存储过程执行 ROLLBACK，外部 SQLTransaction 似乎会丢失其连接，因此任何后续重用事务的尝试都会失败。有没有办法可以在 T-SQL 中回滚但仍保持外部 SQLTransaction？我在想也许保存点在这里可能会有所帮助，但我还不太了解它们。

使这种情况复杂化的是，并不总是有外部事务，所以我不能只删除 T-SQL 回滚，即。有时，sproc 会自行执行；有时在交易的背景下。

切换到 TransactionScope 会让事情变得更容易吗？

感谢您的任何建议......迈克

4

3 回答 3

0

看看这个知识库条目：

发生数据源错误后提交或回滚事务时可能会出现意外异常

在存储过程中回滚事务将导致 ADO.NET 客户端中的任何“外部”事务消失。唯一的解决方案是将您的 Rollback() 调用包装在 try/catch 块中。如果发生这种情况，我认为不可能维持外部交易。

于 2008-12-23T23:44:50.507 回答
0

我建议您考虑将外部事务也放在存储过程中，以便在 TSQL 中维护所有嵌套（使用 EXEC 调用其他存储过程）。SQL Server 是一个非常丰富的开发/数据管理环境，它允许您以 ADO 笨拙地处理的方式来管理您的事务。还要记住，在存储过程中将一堆 SQL 组合在一起几乎总是比通过 ADO 连接进行多次调用更有效。

于 2008-12-23T23:55:08.877 回答
0

您可能会感兴趣查看IMPLICIT_TRANSACTION基本上有了这个，您可以更改存储过程的事务相关模式。在许多情况下，这是一个更简单的解决方案。

于 2008-12-26T06:23:10.403 回答