IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
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 [2017]


Sujet :

MS SQL Server

  1. #1
    Membre chevronné
    Avatar de cavo789
    Homme Profil pro
    Développeur Web
    Inscrit en
    mai 2004
    Messages
    1 339
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 47
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : mai 2004
    Messages : 1 339
    Points : 2 158
    Points
    2 158
    Par défaut 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
    Invité
    Invité(e)
    Par défaut
    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é ?

  3. #3
    Membre chevronné
    Avatar de cavo789
    Homme Profil pro
    Développeur Web
    Inscrit en
    mai 2004
    Messages
    1 339
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 47
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : mai 2004
    Messages : 1 339
    Points : 2 158
    Points
    2 158
    Par défaut
    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
    Invité
    Invité(e)
    Par défaut
    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.

  5. #5
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    mai 2002
    Messages
    21 143
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 21 143
    Points : 50 169
    Points
    50 169
    Billets dans le blog
    1
    Par défaut
    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 +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

  6. #6
    Membre chevronné
    Avatar de cavo789
    Homme Profil pro
    Développeur Web
    Inscrit en
    mai 2004
    Messages
    1 339
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 47
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : mai 2004
    Messages : 1 339
    Points : 2 158
    Points
    2 158
    Par défaut
    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

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    mai 2002
    Messages
    21 143
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 21 143
    Points : 50 169
    Points
    50 169
    Billets dans le blog
    1
    Par défaut
    C'est mieux !

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

  8. #8
    Modérateur

    Profil pro
    dba
    Inscrit en
    janvier 2010
    Messages
    5 643
    Détails du profil
    Informations personnelles :
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : dba

    Informations forums :
    Inscription : janvier 2010
    Messages : 5 643
    Points : 13 070
    Points
    13 070
    Par défaut
    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()

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. Oracle10 Delphi2006 Bde+odbc Stored Proc
    Par cedric.mechler dans le forum Oracle
    Réponses: 1
    Dernier message: 11/07/2006, 10h05
  2. MyISAM -> InnoDB (Problème Stored Proc)
    Par Erakis dans le forum Outils
    Réponses: 8
    Dernier message: 12/12/2005, 20h02
  3. Comment obtenir la date dans une store proc?
    Par Dnx dans le forum Langage SQL
    Réponses: 4
    Dernier message: 17/10/2005, 17h31
  4. Oracle - SQLJ '- Stores Proc Java
    Par kamalito dans le forum Oracle
    Réponses: 1
    Dernier message: 27/09/2005, 12h11
  5. store proc comme fonction
    Par Bernybon dans le forum MS SQL Server
    Réponses: 9
    Dernier message: 12/03/2004, 21h45

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo