Discussion :

[Donpi]

Bonjour,
tout est dans le titre.
Un de vous sait comment le faire ?
A+

[aieeeuuuuu]

Bonjour,

Dans votre trigger "qui ne doit pas être déclenché", vous pouvez faire un test sur TRIGGER_NESTLEVEL, afin qu'il ne fasse rien s'il est imbriqué...

[Lyche]

Juste par curiosité, Est-ce normal, dans votre modèle de base d'avoir autant de trigger et d'avoir des cascades possibles?

Je suis peut-être borné, mais j'ai toujours considéré que les triggers était une fonctionnalité dont on pouvait se passer du moment que les RG sont bien définies lors des développements. Pouvez-vous vous passer d'un des deux trigger? Ou Est-ce impératif pour votre projet?

[Donpi]

Bonjour,
Merci aieeeuuuuu, ça marche bien.

Lyche, j'utilise les triggers pour être sur de garder une certaine cohérence dans ma base lors qu'un développeur va faire une modification à la main dans la DB.
Dans mon cas j'ai un trigger qui me remplit une table de mouvement de stock avec un Update sur lui même.
Et sur la même table j'ai une sorte de trigger d'historique (version standard oblige).
C'est deux sujets différents donc j'aime les avoir dans deux trigger séparés.

Après si on admet qu'il y a autant de façons de faire que de développeur dans le monde, il y a surement moyen de faire proprement et autrement.
Mais c'est cette approche qui à été retenue.

Voilà a+

[Lyche]

Ok, c'est purement un moyen de contrôle alors. Je demandais parce qu'il m'est souvent arrivé de croiser des projets ou des oublis de RG avaient été fait et des trigger étaient faits en grands nombre pour compenser les oublis... Avec, bien entendu tous les problèmes de verrouillages qui se faisaient à cause des cascades de trigger..

Pour votre souci, Est-ce que désactiver temporairement le trigger depuis le premier pourrait être envisageable?

[SQLpro]

Vous pouvez aussi utiliser le paramétrage niveau serveur :

Code :

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

EXEC sp_configure 'nested triggers'

A +