我正在编写一些在数据库表中插入行时需要执行的SQL代码,所以我使用的是AFTER INSERT触发器;代码非常复杂,因此仍然可能存在一些错误.

我发现,如果在执行触发器时发生错误,SQL Server将中止批处理和/或整个事务.这对我来说是不可接受的,因为它会给使用数据库的主应用程序带来问题;我也没有该应用程序的源代码,因此我无法对其进行适当的调试.即使我的触发器失败,我也绝对需要所有数据库操作才能成功.

如何编码我的触发器,以便在发生错误时,SQL Server不会中止INSERT操作？

另外,如何才能执行正确的错误处理,以便我能够确切地知道触发器已经失败？发送带有错误数据的电子邮件对我来说是好的(触发器的主要目的实际上是发送电子邮件),但是如何在触发器中检测错误情况并对其做出反应？

编辑：

感谢有关通过使用除触发器之外的其他内容来优化性能的提示,但是这个代码在长期运行或性能密集的意义上并不“复杂”;它只是构建和发送邮件消息,但为了做到这一点,它必须从各种链接表中检索数据,因为我正在逆向工程这个应用程序,我没有可用的数据库模式,我仍然试图找到我的方式;这就是为什么转换错误或意外/空值仍然可以爬升,导致触发器执行崩溃的原因.

另外,如上所述,我绝对不能对应用程序本身进行调试,也不能修改它以在应用程序层中执行我需要的操作;对应用程序事件作出反应的唯一方法是在应用程序向DB写入某些内容已启动时触发数据库触发器.

最佳答案 如果触发器中的操作很复杂和/或可能长时间运行,并且您不希望活动影响原始事务,那么您需要找到一种方法来解耦活动.

一种方法可能是使用Service Broker.在触发器中,只需创建消息(每行一个)并在途中发送它们,然后在服务中完成剩余的处理.

如果这看起来太复杂,那么较旧的方法是将需要处理的行插入到工作/队列表中,然后让一个工作不断地从那里拉行来完成工作.

无论哪种方式,您现在都没有阻止原始事务提交.