SQL Server 中的同步触发器
在 Microsoft SQL Server 中：
我在表 ACCOUNTS 中添加了一个插入触发器，它根据插入的值插入到表 BLAH 中。 这些插入仅来自一个地方，而且一次只发生一个。 （我的意思是，一个事务中永远不会有两次插入 - 理论上，两个 Web 用户可以单击提交并以近乎同步的方式完成插入。）
我是否需要调整触发器来处理多于一行在插入中，为触发器创建的特殊表 - 或者每个单独的插入事务是否单独启动触发器？
In Microsoft SQL Server :
I've added an insert trigger my table ACCOUNTS that does an insert into table BLAH based upon the inserted values.
The inserts come from only one place, and those happen one at a time. (By that, I mean, that there's never two inserts in a transaction - two web users could, theoretically click submit and have their inserts done in a near-simulataneous way.)
Do I need to adapt the trigger to handle more than one row being in inserted, the special table created for triggers - or does each individual insert transaction launch the trigger separately?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
每次插入都会调用触发器。但是，如果单个插入添加多于一行，则触发器仅被调用一次，因此您的触发器必须能够处理多条记录。
粒度是 INSERT 语句级别而不是事务级别。
所以不，如果您有两个事务插入同一个表中，它们将各自自动调用触发器。
鲍勃
Each insert calls the trigger. However, if a single insert adds more than one row the trigger is only called once, so your trigger has to be able to handle multiple records.
The granularity is at the INSERT statement level not at the transaction level.
So no, if you have two transactions inserting into the same table they will each call the trigger ATOMICALLY.
BOb
在您的情况下，每个插入都发生在自己的事务中，并单独触发触发器，所以您应该没问题。如果曾经有过在同一事务中进行两次插入的情况，则必须修改触发器以从“插入”表执行基于集合的插入，或者在需要额外处理时执行某种游标。
in your situation each insert happens in its own transaction and fires off the trigger individually, so you should be fine. if there was ever a circumstance where you had two inserts within the same transaction you would have to modify the trigger to do either a set based insert from the 'inserted' table or some kind of cursor if additional processing is necessary.
如果您在一个事务中只执行一次插入，我认为没有任何理由需要插入更多行，除非存在递归触发器调用的可能性。
不过，如果您将来更改应用程序的行为而忘记更改触发器，则可能会给您带来麻烦。因此，可以肯定的是，我宁愿实现触发器，就好像它可以在
inserted中包含多行。If you do only one insert in a transaction, I don't see any reason for more rows to be in
inserted, except if there was a possibility of recursive trigger calls.Still, it could cause you troubles if you'd change the behavior of your application in future and you forget to change the triggers. So just to be sure, I would rather implement the trigger as if it could contain multiple rows in
inserted.