[2005] TRIGGERS interdépendants

Bonjour,

Je suis en train d'écrire 2 triggers pour 2 tables, et je m'interroge sur les conflits potentiels qui existent peut-être.

Le trigger n°1 (TR1) est un trigger AFTER UPDATE sur la table n°1 (T1).
Le trigger n°1 (TR2) est un trigger AFTER UPDATE sur la table n°2 (T2).

Dans TR1, se fait parfois une opération de mise à jour sur la table T2.
Dans TR2, il est parfois nécessaire de receuillir des informations de T1.

Donc je peux avoir un scénario où, je fais une opération de mise à jour sur T1, qui sera suivie d'un appel au trigger TR1 qui lui fera une opération de mise à jour sur T2, qui sera suivie d'un appel au trigger TR2 qui lui devra lire T1.


Est-ce que cela peut poser des problèmes (vis à vis des lock, de la consistance des données, etc.) ?

Merci.

Votre problematique exposée est trop vaste pour que l'on puisse vous répondre dans les meilleures conditions.
Il manque:
- La définition des tables
- La définition des triggers
- La fréquence d'utilisation
- La volumétrie
- Le transaction isolation level requis
- Les requirements business (aspect fonctionnel)

Je vous suggère d'effectuer une série de tests, surtout en incluant des cas "borderlines" afin d'analyser cela par vous meme. J'entend par cas "borderlines" les cas qui risquent de poser le plus de soucis.

D'autre part, si cela vous semble limite, songez à une autre manière peut etre plus élégante d'implementer votre solution... Stored procedure ?

Je ne vous demande pas de résoudre mon problème, je vous demande de m'aider à l'aborder par moi même.
Et, à part vous noyez dans une plétôre de détails vous donnez tous les éléments n'aura aucun effet.
Je dis cela en toute sincérité.

bonjour,
Vous pouvez activer/désactivez cette possibilité via sp_configure option nested triggers.
Par défaut et afin de "limiter" les cascades le niveau d'imbrication est limité à 32.

Les verrous ne sont libéré que lorsque la transaction est finie.