Триггер SQL Server не вставляет строку - PullRequest
2 голосов
/ 16 февраля 2012

Я работаю с 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

Он прекратил выполнение пакета, прерванного, но, кажется, никогда не вставлял ничего в мою историческую таблицу ... Я читал об этой теме, и это должно работать, я думаю. Но это не так ...

Кто-нибудь еще уже имел эту проблему, и как я могу это исправить?

Я делаю простую вставку в, чтобы проверить мой триггер.

1 Ответ

3 голосов
/ 16 февраля 2012

К сожалению, вы лаете не на то дерево. Вы не можете играть с транзакциями таким образом.

Если единственной проблемой были неудачные вставки, вы можете просто кодировать чек вокруг вашей вставки. Или просто следите за тем, чтобы ограничения на вашем столе точно отражали его использование. Но, поскольку вы также обеспокоены продолжительностью процесса, вызывающего тайм-аут команды, это не покроет вас полностью (на самом деле, это сделает этот тайм-аут очень немного более вероятным).

Единственный подход, который я вижу в работе, заключается в том, чтобы значительно упростить оператор вставки и вставить что-то (все данные или только метку времени и идентификатор?) В таблицу хранения, которая не имеет ограничений или индексов. Затем вам понадобится процесс на стороне сервера, который вызывается повторно для обработки таблицы хранения.

Поскольку в вашем случае ведется ведение исторического журнала, возможно, такой вариант может быть таким же простым, как удаление всех ограничений из таблицы исторических данных. Все решения немного грязные, но тогда требования вашего начальника кажутся немного необычными; На мой взгляд, ответом должно быть планирование мощности.

Я не знаю, подходит ли это вашему сценарию в реальном мире, но я надеюсь, что это поможет.

...