Comment identifier les triggers qui mettent à jour une table SQL Server

Objectif** : vous donner une méthode fiable pour retrouver tous les déclencheurs (triggers) susceptibles de modifier une table donnée (ex. tb_xxx).
Exclusion volontaire : la DMV sys.dm_sql_referencing_entities (Point 3) est écartée ici, car elle retourne des résultats incomplets dans de nombreux scénarios (objets anciens, SQL dynamique, bases migrées, etc.).

1. Pourquoi traquer les triggers ?

• Débogage & performance : un trigger « caché » peut ralentir vos INSERT/UPDATE/DELETE sans que vous le sachiez.
• Maintenance & refonte : avant toute évolution de schéma (ex. refactorisation de tables), il faut connaître les objets dépendants.
• Conformité & audit : certaines normes (SOX, ISO 27001, PCI‑DSS) exigent l’inventaire complet des mécanismes de mise à jour automatique.

2. Méthode 1 : lister les triggers attachés directement à la table

SELECT  
    tr.name                             AS TriggerName,
    s.name + '.' + t.name               AS TableName,
    tr.is_disabled                      AS IsDisabled,
    tr.is_instead_of_trigger            AS IsInsteadOf
FROM sys.triggers AS tr
JOIN sys.tables   AS t ON t.object_id = tr.parent_id
JOIN sys.schemas  AS s ON s.schema_id = t.schema_id
WHERE tr.parent_id = OBJECT_ID('dbo.tb_xxx');   -- ajustez le schéma si besoin

Points clés

• Ne retourne que les triggers AFTER ou INSTEAD OF définis sur tb_xxx.
• Le champ is_disabled indique si le trigger est actuellement désactivé.

3. Méthode 2 : repérer les triggers externes via recherche plein‑texte

Si d’autres tables possèdent des triggers qui mettent à jour tb_xxx, ils ne seront pas listés par la méthode 1.
La technique la plus simple est de scanner le texte SQL des triggers :

SELECT  
    tr.name                               AS TriggerName,
    s.name + '.' + t.name                 AS ParentTable,
    tr.is_disabled                        AS IsDisabled,
    sm.definition                         AS TriggerDefinition
FROM sys.triggers        AS tr
JOIN sys.sql_modules     AS sm ON sm.object_id = tr.object_id
JOIN sys.tables          AS t  ON t.object_id  = tr.parent_id
JOIN sys.schemas         AS s  ON s.schema_id  = t.schema_id
WHERE sm.definition LIKE '%tb_xxx%';         -- ou COLLATE Latin1_General_CI_AI si besoin

Avantage : universel, rapide, couvre même le SQL dynamique.
Limite : peut remonter de faux positifs si une autre table contient un nom ressemblant à tb_xxx.

4. Méthode 3 : vue de dépendances cataloguées (plus robuste, mais pas infaillible)

SELECT  
    OBJECT_SCHEMA_NAME(o.object_id) + '.' + o.name AS TriggerName,
    OBJECT_SCHEMA_NAME(o.parent_object_id) + '.' + OBJECT_NAME(o.parent_object_id) AS ParentTable
FROM sys.objects                   AS o
JOIN sys.sql_expression_dependencies AS d ON o.object_id = d.referencing_id
WHERE o.type = 'TR'                            -- uniquement les triggers
  AND d.referenced_id = OBJECT_ID('dbo.tb_xxx');

Points clés

• SQL Server enregistre les dépendances à chaque création ou recompilation d’objet.
• Pas de détection si le trigger utilise du SQL dynamique ou si la base a été montée depuis un bak très ancien sans recompilation.
• Combinez toujours avec la méthode 2 pour être exhaustif.

5. Méthode 4 : interface graphique SSMS (rapide pour un contrôle visuel)

1. Object Explorer : clic droit sur votre base → View → Object Explorer Details (F7).
2. Recherchez tb_xxx dans la zone de recherche.
3. Dans le panneau de détails, la colonne Referenced By liste les objets dépendants (incluant les triggers).
4. Double‑clic sur un trigger ouvre le code pour inspection rapide.

Astuce : activez l’option Track Changes dans SSMS pour surligner immédiatement le mot‑clé tb_xxx dans le code ouvert.

6. Audit en temps réel (optionnel)

Même après inventaire, il est prudent de vérifier ce qui s’exécute réellement en production :

7. Checklist rapide

8. Conclusion

Identifier l’ensemble des triggers susceptibles de modifier une table est indispensable pour :

• Stabiliser les performances (éviter des déclencheurs coûteux non documentés).
• Sécuriser les migrations et refontes de schéma.
• Répondre aux exigences d’audit et de conformité.

En combinant :

1. La liste des triggers attachés (sys.triggers),
2. Le scan plein‑texte du code (sys.sql_modules),
3. Les dépendances cataloguées (sys.sql_expression_dependencies),
4. Le contrôle visuel dans SSMS,

…vous obtenez une vue exhaustive, fiable et directement exploitable pour vos chantiers de maintenance ou d’optimisation. À intégrer sans tarder dans vos bonnes pratiques DBA !