SQL Server 触发器不插入行

发布于 2025-01-06 06:04:17 字数 1574 浏览 1 评论 0原文

我使用 SQL Server 2008 R2

我有一个简单的触发器

CREATE TRIGGER [dbo].[T_Personne_ITrig] ON [dbo].[Personne] FOR INSERT AS 
BEGIN
SET NOCOUNT ON 

insert into syn_HistoriquePersonne 
     (hpers_Timestamp, Supprime, ID, Nom, Prenom, Champ1, 
      Champ2, Champ3, Champ4 SiteAssocie)
 select  GETDATE(), 0, ID, Nom, Prenom, Champ1, Champ2, Champ3, 
       Champ4,  SiteAssocie
from inserted
END

它工作正常。问题是,我正在开发一个代码库很糟糕的程序,所以我的老板不想触发导致表 Personne 的回滚,即使它失败了。我知道这确实不太可能,但他害怕在数据库活动巨大的情况下超时……无论如何

,所以我搜索了有关在触发器中提交的信息。并将触发器更改为:

CREATE TRIGGER [dbo].[T_Personne_ITrig] ON [dbo].[Personne] FOR INSERT AS 
BEGIN
SET NOCOUNT ON 

COMMIT

insert into syn_HistoriquePersonne 
     (hpers_Timestamp, Supprime, ID, Nom, Prenom, Champ1, 
      Champ2, Champ3, Champ4 SiteAssocie)
select  GETDATE(), 0, ID, Nom, Prenom, Champ1, Champ2, Champ3, 
       Champ4,  SiteAssocie
from inserted
END

但触发器不断射击消息

事务在触发器中停止,批次中止。

所以我这样做了:

CREATE TRIGGER [dbo].[T_Personne_ITrig] ON [dbo].[Personne] FOR INSERT AS 
BEGIN
SET NOCOUNT ON 

COMMIT
BEGIN TRAN
insert into syn_HistoriquePersonne 
     (hpers_Timestamp, Supprime, ID, Nom, Prenom, Champ1, 
      Champ2, Champ3, Champ4, SiteAssocie)
 select  GETDATE(), 0, ID, Nom, Prenom, Champ1, Champ2, Champ3, 
       Champ4,  SiteAssocie
 from inserted
 END

它停止执行批处理中止,但它似乎永远不会在我的历史表中插入任何内容......我读到了有关该主题的内容,我认为这应该有效。但它并没有...

其他人已经遇到过这个问题,我该如何解决这个问题?

我正在做简单的插入来测试我的触发器。

I work with SQL Server 2008 R2

I have a simple trigger

CREATE TRIGGER [dbo].[T_Personne_ITrig] ON [dbo].[Personne] FOR INSERT AS 
BEGIN
SET NOCOUNT ON 

insert into syn_HistoriquePersonne 
     (hpers_Timestamp, Supprime, ID, Nom, Prenom, Champ1, 
      Champ2, Champ3, Champ4 SiteAssocie)
 select  GETDATE(), 0, ID, Nom, Prenom, Champ1, Champ2, Champ3, 
       Champ4,  SiteAssocie
from inserted
END

It works properly. Problem is, I work on a program with an horrible code base so my boss don't want to trigger to ever cause a rollback on the table Personne even if it fails. I know it's really improbable, but he's scared of timeout in case of huge database activity... ANYWAY

So I searched about committing in triggers. And changed the trigger to :

CREATE TRIGGER [dbo].[T_Personne_ITrig] ON [dbo].[Personne] FOR INSERT AS 
BEGIN
SET NOCOUNT ON 

COMMIT

insert into syn_HistoriquePersonne 
     (hpers_Timestamp, Supprime, ID, Nom, Prenom, Champ1, 
      Champ2, Champ3, Champ4 SiteAssocie)
select  GETDATE(), 0, ID, Nom, Prenom, Champ1, Champ2, Champ3, 
       Champ4,  SiteAssocie
from inserted
END

But the trigger kept shooting message

Transaction stopped in trigger, batch aborted.

So I made it like that :

CREATE TRIGGER [dbo].[T_Personne_ITrig] ON [dbo].[Personne] FOR INSERT AS 
BEGIN
SET NOCOUNT ON 

COMMIT
BEGIN TRAN
insert into syn_HistoriquePersonne 
     (hpers_Timestamp, Supprime, ID, Nom, Prenom, Champ1, 
      Champ2, Champ3, Champ4, SiteAssocie)
 select  GETDATE(), 0, ID, Nom, Prenom, Champ1, Champ2, Champ3, 
       Champ4,  SiteAssocie
 from inserted
 END

It stopped doing the batch aborted, but it seems to never insert anything in my historic table... I read about the subject and this should work I think. But it doesn't...

Anyone else already had that problem and how can I fix that?

I am doing simple insert into to test my trigger.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

不美如何 2025-01-13 06:04:17

不幸的是你找错了树。你不能以这种方式玩交易。

如果唯一担心的是插入失败,您可以简单地在插入周围编写检查代码。或者只是非常彻底地确保表上的约束准确反映其使用情况。但是,由于您还担心导致命令超时的过程的持续时间,因此这不会完全覆盖您(事实上,它会使超时的可能性稍大一些)。

我认为有效的唯一方法是大幅简化插入语句,并将某些内容(所有数据,或只是时间戳和 ID?)插入到没有约束或索引的保存表中。然后,您将需要一个被重复调用的服务器端进程来处理您的保存表。

由于您的情况似乎只是维护历史日志,因此选项可能就像从 historique 表中删除所有约束一样简单。所有的解决方案都有点肮脏,但是你老板的要求似乎有点不寻常;在我看来,答案实际上应该是容量规划。

我不知道这是否符合您的现实世界场景,但我希望它有所帮助。

Unfortunately you're barking up the wrong tree. You can't play with transactions in that way.

If the only concern was failed inserts, you could simply code a check around your insert. Or just be very throrough in ensuring the constraints on your table accurately reflect it's use. But, as you're also concerned about the duration of the process causing a command time-out, this won't cover you entirely (in fact it'll make that time-out very slightly more likely).

The only approach that I can see working is to massively simplify the insert statement, and insert something (all the data, or just the timestamp and id?) into a holding table which has no constraints, or indexes. You would then need a server side process that is called repeatedly to process your holding table.

As your case seems to be just maintaining a historic log, perhaps an option could be as simple as removing all constraints from the historique table. All the solutions are a bit dirty, but then the requirement from your boss seems a bit unusual; the answer should really be capacity planning in my opinion.

I don't know if that fits with your real world scenario, but I hope it helps.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文