Discussion :

[XDeus]

Bonjour,

Je me trouve face à une situation qui pose une colle.
Je suis en charge de l'exploitation d'une CRM Métier, hébergée sous SQL Server 2008 R2.

Pour faire des économies et ne pas sortir du standard de l'éditeur côté programme, nous avons mis en place certains contrôles et traitements via des triggers. Ceux-ci qui sont devenus avec le temps de véritables "millefeuilles".

Pour simplifier la situation, j'ai deux tables, les appels d'un client (table [aplcall]) et les commentaires d'appels (table [aplcallc]).

Nous avons :
* un trigger "t_upd_aplcall" sur la table des appels ([aplcall]) qui intervient après la mise à jour (AFTER UPDATE) d'une ligne pour effectuer divers contrôles et évènements.
* un trigger "t_ins_aplcallc" sur la table des commentaire d'appels ([aplcallc]) qui intervient après une insertion (FOR INSERT) d'une ligne de commentaire, son but est d'incrémenter le compteur de ligne de commentaires dans la table appel ([aplcall_nbcallc]) via une requête UPDATE.

De tel sorte que lorsqu'un appel est modifié avec un ajout de x ligne de commentaire, mon trigger "t_upd_aplcall" est exécuté X+1 fois.

Je souhaiterais savoir quel type de syntaxe IF je dois utiliser en entête du trigger, pour sortir du traitement lorsque celui-ci est appelé par le trigger "t_ins_aplcallc". En effet la mise à jour du compteur de commentaire d'appel ne fait l'objet d'aucun traitement dans le trigger "t_upd_aplcall" et celui-ci étant important, il me "plombe" les temps d’exécution étant appelé à chaque insertion d'une ligne de commentaire.

Merci d'avance.
A vous lire.
XDeus.

[XDeus]

Bonjour,

J'ai déjà tenté de désactiver les déclencheurs imbriqués, mais ceci a été relativement catastrophique.
Les requêtes d'insertion et mise à jour, s'en sont trouvées très ralenties, m'occasionnant un volume important de requête en attente.

Au final j'ai réactivé l'option ("nested triggers" à 1) après un redémarrage de l'instance.

Cordialement.
XDeus.

[SQLpro]

C'est effectivement sur les triggers imbriqués qu'il faut jouer en les interdisant.

Il est normal que vous ayez un ralentissement des requêtes après modification du comportement du serveur ou de la base, car tous les plans en cache s'en trouvent invalidé.

Les performances redeviendront normale au bout de quelques temps.

Arrêter une instance est la pire des solutions. Un Serveur SQL ne doit jamais être arrêté !

A +

[rudib]

regardez du côté de la fonction TRIGGER_NESTLEVEL : http://technet.microsoft.com/en-us/l.../ms182737.aspx

[elsuket]

Ou encore l'option d'instance nested triggers

@++