trigger "update sur insert" avec insertion multiple

Bonjour,

J'ai un requete qui insert des milliers de lignes avec un :
INSERT INTO stat (col1, col2, col3, ...)
SELECT cola, colb, colc, ... FROM toto

Est ce que c'est possible, avec un trigger, de faire un update sur chacune de ces lignes pour qu'elles aillent prendre une valeur (qui varie selon les valeurs insérées dans les colonnes) dans une autre table ?
Puis-je m'appuyer sur la table inserted ?

Aujourd'hui, après l'insert, je passe ligne par ligne ma table stat avec un curseur et j'update la ligne, mais c'est très long.

Merci pour votre aide

Bonjour,

Citation:

---

je passe ligne par ligne ma table stat avec un curseur et j'update la ligne, mais c'est très long.

---

Vous avez dit deux fois la même chose : "curseur" et "très long" ;)
N'utilisez les curseurs que lorsque vous avez exploré toutes les autres solutions possibles.
Dès SQL Server 2005, les cas où on ne peut pas se passer de curseur sont hyper-rares (SQL Server 2005 a introduit les CTE récursives notamment)

Citation:

---

Est ce que c'est possible, avec un trigger, de faire un update sur chacune de ces lignes pour qu'elles aillent prendre une valeur (qui varie selon les valeurs insérées dans les colonnes) dans une autre table ?
Puis-je m'appuyer sur la table inserted ?

---

Tout à fait.
Voici un exemple un peu générique pour vous lancer :

Code:

---

1 2 3 4 5 6 7 8 9 10 11

CREATE TRIGGER TR_A_I_STAT ON dbo.STAT AFTER INSERT AS BEGIN UPDATE dbo.STAT SET colonnesDeSTAT = A.colonnes FROM dbo.STAT AS S INNER JOIN dbo.autreTable AS A ON S.uneClé = A.uneClé INNER JOIN INSERTED AS I ON S.CléPrimaire = I.CléPrimaire END

---

La documentation T-SQL sur les triggers se trouve ici

Dans un trigger vous avez "accès" à deux tables virtuelles : INSERTED et DELETED.
Ces deux tables virtuelles ont strictement la même structure que la table cible de la mise à jour (INSERT | UPDATE | DELETE).
La table virtuelle INSERTED contient les nouvelles valeurs insérées dans la table, et la table DELETED les valeurs qui ont été écrasées dans la table.
Ainsi :
- sur un INSERT, vous avez accès seulement à INSERTED
- sur un UPDATE, vous avez accès à INSERTED et DELETED
- sur un DELETE, vous avez accès seulement à DELETED.

Mais peut-être que vous pourriez faire cette mise à jour dans une procédure stockée, sauf si vous souhaitez "centraliser" la mise à jour.
Retenez que les triggers sont gourmands en ressources ;)

@++ ;)

Merci beaucoup pour ta réponse
Effectivement ça marche plutôt bien :)

Sur un petit volume de 40.000 Lignes
avec trigger, 9 secondes
avec curseur 51 secondes

Est ce qu'il est déconseillé d'enchainer les trigger ?
ex : un insert qui execute un insert qui execute un autre insert qui execute un update ?

Merci encore

Bonjour,

Citation:

---

Est ce qu'il est déconseillé d'enchainer les trigger ?

---

Oui, les triggers sont gourmands en ressources ;)

Citation:

---

ex : un insert qui execute un insert qui execute un autre insert qui execute un update ?

---

Vous voulez dire : un trigger sur INSERT qui déclenche un autre trigger sur INSERT dans sur une autre table, qui à son tour déclenche un trigger sur UPDATE sur une autre table ?
Si c'est bien cela, imaginez le verouillage que vous mettez en place ... à mon avis, si votre base de données est intensément utilisée (beaucoup de modifications, peu de lectures) vous aurez très vite des problèmes de performance ...
Écrivez plutôt une jeu de procédures stockées suffisamment découpé pour avoir une souplesse de codage élevée (vous pouvez appeler une procédure dans une autre procédure), vous y gagnerez ;)

Avez-vous vérifié que les colonnes clés des tables participant à votre requête sont correctement indexées ?

@++ ;)

Merci pour votre réponse !