我正在寻找一种方法来继续执行事务，尽管在插入低优先级数据时出现错误。看起来真正的嵌套事务可能是一个解决方案，但 SQL Server 2005/2008 不支持它们。另一种解决方案是有逻辑来确定错误是否严重，但这似乎也不可能。
以下是有关我的方案的更多详细信息：
使用 ADO.NET/C# 定期将数据插入到数据库中，虽然其中一些是至关重要的，但也可能会毫无问题地丢失一些数据。插入完成后，将对数据进行一些计算。（重要的和非重要的）整个过程都在事务中，所以一切都保持同步。
目前，使用事务保存点，并对非重要插入期间发生的异常进行部分回滚。但是，这不适用于“批量中止”错误，它会自动回滚整个事务。我知道有些错误很严重，但是 SQL Server 将诸如失败的强制转换之类的事情视为批处理中止错误。（有关批处理错误的信息）如果这些错误发生在低优先级数据上，我正在尝试防止它们降低整个插入。
如果我所描述的内容是不可能的，我愿意考虑任何替代方法来实现数据完整性，但允许非重要插入失败。
谢谢你的帮助。
不幸的是，不能像您描述的那样完成（对嵌套事务的完全支持将是关键）。我能想到的几件事过去曾被用来解决这个问题：
最好的选择可能是将命令分成可以明确执行的重要/非重要命令，自然这将要求它们彼此不依赖于顺序
还可以使用基于消息传递的方法（请参阅Service Broker），您可以在其中内联执行主要命令并将非主要命令推送到队列中以便稍后/单独执行。推送到队列将是批处理中的事务，但是当您从队列中弹出时命令的执行将是分开的。这也将要求它们不依赖于彼此的顺序。
如果依赖于顺序，您可以对所有内容使用消息传递方法，这将确保顺序并且每个操作可以有单独的消息，然后将它们组合在一起（通过对话组）将允许您按顺序将它们从队列中拉出并使用每种“类型”操作（即主要与非主要）的单独事务。如果所有分组消息都必须是单个自主操作，那么这将需要您进行一些特殊编码，但可以完成。
我什至不愿提及这个选项，因为它是一个糟糕的选项，但为了全面披露，我想如果你认为它合适，你可以自行考虑它（但它绝对不是一个适用于几乎任何场景的架构）。您可以使用 xp_cmdshell 调用命令行并为非关键任务执行 sqlcmd/osql - 此 sqlcmd 执行将与您正在执行的模块在单独的事务中，并且只需忽略 xp_cmdshell 故障应该允许主批处理继续。
这些是一些想法...
您能否将您的导入到一个临时位置，仅对重要部分使用事务。加载临时位置后，吸收任何非关键错误后，您可以在单个事务中将数据复制到其最终目的地。取决于您所做工作的性质，但可能是一个可行的选择。