SQL更新触发器并不总是更新
因此，我有一个简单的更新触发器，它将删除的数据复制到相同格式的另一个表中，并添加修改日期。它工作得很好，但是在应用程序代码中有很多情况下，执行更新时实际上不会更改任何值。
我试图避免这些被纳入审计表中。
有没有人对我如何解决这个问题有任何建议，不更改我的应用程序代码。可能是对行进行简单比较以检查更改？
谢谢
So I've got a simple update trigger that copies the the deleted data into another table of the same format, with the addition of the modified date. It works great, however there are a lot of cases in the application code when an update is performed that doesn't actually change any values.
I'm trying to avoid these being picked up in the audit tables.
Does anybody have any suggestions on how I can fix this, without changing my application code. Possibly a simple comparison of the rows to check for changes?
Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
不幸的是，它是触发器中的逐列比较
编辑：为了不保证100%的准确性，您可以使用校验和(*)。 HashBytes 更好
Unfortunately, it is a column by column comparison in the trigger
Edit: for not guaranteed 100% accuracy, you can use CHECKSUM(*). HashBytes is better
此文章详细介绍了一个在某些情况下有效的有趣解决方案。他从当前和已删除的表中选择 FOR XML，通过 HashBytes() 运行这些表并对结果进行比较。
这篇文章包括写得好的来源。我能够快速修改它以在我的架构中使用。我放弃了 HashBytes() 转换，只比较 XML 值，以避免 HashBytes() 的潜在问题。我已经稍微测试了该解决方案，它似乎按预期工作。
文章的评论部分也有一个链接，指向另一篇关于该主题的有趣文章。
The author of this article details an interesting solution that will work in some cases. He selects from the current and deleted tables FOR XML, runs those through HashBytes() and does a comparison of the results.
The article includes well-written source. I was able to modify it quickly for use in my schema. I dropped the HashBytes() conversion and just compared the XML values in order to get around potential issues with HashBytes(). I've tested the solution lightly, and it seems to work as expected.
There's a link in the comments section of the article to another interesting article on the subject, as well.