Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

MS SQL Server Discussion :

DISABLE TRIGGER in stored proc


Sujet :

MS SQL Server

  1. #1
    Membre expérimenté
    DISABLE TRIGGER in stored proc
    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;
    Christophe (cavo789)
    Mes scripts Open Source : https://github.com/cavo789

  2. #2
    Expert éminent
    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é ?
    les règles du forum - mode d'emploi du forum
    Aucun navigateur ne propose d'extension boule-de-cristal : postez votre code et vos messages d'erreurs. (Rappel : "ça ne marche pas" n'est pas un message d'erreur)
    JE NE RÉPONDS PAS aux questions techniques par message privé.

  3. #3
    Membre expérimenté
    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
    Christophe (cavo789)
    Mes scripts Open Source : https://github.com/cavo789

  4. #4
    Expert éminent
    Citation Envoyé par cavo789 Voir le message
    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.
    les règles du forum - mode d'emploi du forum
    Aucun navigateur ne propose d'extension boule-de-cristal : postez votre code et vos messages d'erreurs. (Rappel : "ça ne marche pas" n'est pas un message d'erreur)
    JE NE RÉPONDS PAS aux questions techniques par message privé.

  5. #5
    Rédacteur

    Citation Envoyé par cavo789 Voir le message
    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 +
    Cette signature n'a pas pu être affichée car elle comporte des erreurs.

  6. #6
    Membre expérimenté
    Merci à vous deux; merci Frédéric pour ta confirmation. Je vais donc laisser le trigger en place.
    Christophe (cavo789)
    Mes scripts Open Source : https://github.com/cavo789

  7. #7
    Rédacteur

    C'est mieux !

    A +
    Cette signature n'a pas pu être affichée car elle comporte des erreurs.

  8. #8
    Modérateur

    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()

###raw>template_hook.ano_emploi###