Discussion :

[cavo789]

Bonjour à tous

Quelqu'un peut-il me confirmer la portée d'un DISABLE TRIGGER dans une stored proc comme illustré ci-dessous ?

Est-ce que le DISABLE n'est fait que pour cette seule procédure ou pour la base de données (càd que si j'oublie d'écran un ENABLE TRIGGER avant de sortir); le trigger risque-t-il d'être toujours inactif.

Cette question pour la raison suivante : dans ma stored proc j'ai plusieurs IF statements afin de valider certaines conditions et si elles ne sont pas rencontrées, je fais un RETURN pour quitter la stored proc sans prendre action. Oui mais, avant le return, dois-je prévoir un ENABLE TRIGGER ou pas ? (et donc pour chaque return un enable trigger plus un dernier tout au bas de la stored proc).

Merci pour vos avis.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
 
ALTER PROCEDURE [dbo].[MaintaineIndexes] 
AS
BEGIN
 
DISABLE TRIGGER dbo.triggerName ON dbo.tableName; 
 
IF (...) 
    BEGIN
         /* ... */
         ENABLE TRIGGER dbo.triggerName ON dbo.tableName;   /* <--- Est-ce nécessaire? */
         RETURN
    END
 
 
...
 
 
ENABLE TRIGGER dbo.triggerName ON dbo.tableName;  /* <--- Est-ce nécessaire? */
END;

[Invité]

Disable trigger désactive le déclencheur partout, ce n'est pas juste pour la session en cours.
Mettons que ça me semble une très mauvaise idée qu'une procédure joue avec ça.
Qu'est-ce qui se passe des données pour les autres sessions qui entrent des données pendant le déroulement de procédure alors que le déclencheur est arrêté ?

[cavo789]

Merci pour ton éclairage.

Peux-tu me conseiller sur la bonne approche ?

J'ai un trigger (première fois que j'en crée) qui, sur une action de type UPDATE sur une table, va mettre à jour une colonne type LastUpdate (date/time donc).

Si je fais un UPDATE maTable SET UneColonneQuelconque = 'Une valeur', le trigger a donc pour vocation de mettre à jour la colonne LastUpdate dans cette même table. Quelque chose de basique je pense. L'objectif étant qu'un logiciel qui analyse la table maTable puisse détecter qu'une mise-à-jour a été faite et qu'il doit faire un traitement de son côté.

Par souci d'optimisation / rigueur, je me dis que si mon UPDATE contient déjà cette assignation(UPDATE maTable SET LastUpdate=GETDATE(), UneColonneQuelconque = 'Une valeur'); il n'est pas nécessaire que le trigger fasse le job puisque déjà fait. Et ça, c'est le cas de ma stored procedure : cette usp gère la colonne LastUpdate au sein de son traitement.

Mon objectif final étant : si, en mode cowboy dans ma DB, je lance à la main un UPDATE ... je veux que le trigger garantisse que LastUpdate ait été mis-à-jour.

Du coup, j'avais pensé le désactiver pour ma stored proc et strictement dans le cadre de l'exécution de cette procédure-là (je n'ai jamais eu l'intention de désactiver le trigger globalement).

Est-ce possible ? Comment faire ?

ou faut-il s'en moquer et lancer le trigger quand même dans tous les cas ?

Merci

[Invité]

Par souci d'optimisation / rigueur, je me dis que si mon UPDATE contient déjà cette assignation(UPDATE maTable SET LastUpdate=GETDATE(), UneColonneQuelconque = 'Une valeur'); il n'est pas nécessaire que le trigger fasse le job puisque déjà fait. Et ça, c'est le cas de ma stored procedure : cette usp gère la colonne LastUpdate au sein de son traitement.

Ça me semble bien plus raisonnable de laisser le trigger faire sa job que de le désactiver à la volet pour gagner quelques pouïèmes de secondes lors du traitement.

[SQLpro]

Merci pour ton éclairage.

Peux-tu me conseiller sur la bonne approche ?

J'ai un trigger (première fois que j'en crée) qui, sur une action de type UPDATE sur une table, va mettre à jour une colonne type LastUpdate (date/time donc).

Si je fais un UPDATE maTable SET UneColonneQuelconque = 'Une valeur', le trigger a donc pour vocation de mettre à jour la colonne LastUpdate dans cette même table. Quelque chose de basique je pense. L'objectif étant qu'un logiciel qui analyse la table maTable puisse détecter qu'une mise-à-jour a été faite et qu'il doit faire un traitement de son côté.

Par souci d'optimisation / rigueur, je me dis que si mon UPDATE contient déjà cette assignation(UPDATE maTable SET LastUpdate=GETDATE(), UneColonneQuelconque = 'Une valeur'); il n'est pas nécessaire que le trigger fasse le job puisque déjà fait. Et ça, c'est le cas de ma stored procedure : cette usp gère la colonne LastUpdate au sein de son traitement.

Dans SQL Server les déclencheurs peuvent être réentrant :

• par récursivité : par défaut désactivé (réglage au niveau base)
• par rebond : par défaut c'est activé (réglage au niveau serveur (sp_configure)

Donc, pas d'inquiétude à avoir pour la réentrance...

maintenant désactiver un trigger est un opération dangereuse car cela modifie le comportement de tous les accès à cette table...

Donc, le laisser faire son job !

A +

[cavo789]

Merci à vous deux; merci Frédéric pour ta confirmation. Je vais donc laisser le trigger en place.

[SQLpro]

C'est mieux !

A +

[aieeeuuuuu]

Bonjour,

Je suis relativement d'accord avec ce qui a été dit plus haut.
Cependant, vous pourriez mesurer l'impact du trigger (activé/désactivé) lors de l'execution de la PS.

Le cas échéant, vous pourriez modifier plutôt le trigger afin qu'il ne mette à jour la colonne LastUpdate que si celle-ci n'est pas déjà mise à jour par la requête qui a declenché le trigger. Pour cela, vous pouvez utiliser la fonction UPDATE()