Je zou de trigger op A iets kunnen laten doen om de trigger op B te waarschuwen dat hij niet hoeft te vuren. Er zijn verschillende wensen om een staat voor een sessie op te zetten. De eenvoudigst mogelijke benadering zou zijn om zoiets te doen als een pakket te maken met een booleaanse variabele bypass_checks_on_b die je hebt ingesteld op TRUE voordat u de UPDATE . uitvoert op A, ingesteld op FALSE eenmaal de UPDATE voltooit en controleer vervolgens de status van deze variabele in uw trigger op B voordat u uw validaties uitvoert. Je zou ook iets soortgelijks kunnen doen met een tijdelijke tabel of een context in plaats van een pakket te gebruiken. Minder efficiënt, je zou de call-stack in je trigger op B mogelijk kunnen ontleden om te zien of de trigger op A zich in de call-stack bevindt, maar dat zou nogal lelijk zijn.
Ik zou echter heel voorzichtig zijn met deze hele architectuur. Als je merkt dat je triggers op A hebt die ervoor zorgen dat triggers op B worden geactiveerd die A willen bevragen, is het bijna altijd zo dat je veel te veel logica in triggers hebt gestopt en dat je veel beter geholpen zou zijn met bewegen die logica in een opgeslagen procedurelaag die kan worden aangeroepen in plaats van dat de toepassingen directe invoegingen of updates uitvoeren. Als je te veel logica in triggers duwt, krijg je een systeem dat erg moeilijk te begrijpen is omdat het niet duidelijk is als je naar de applicatiecode kijkt wat voor soort bijwerkingen verschillende statements hebben. En je eindigt met een zeer stateful code waarbij je veel paden hebt door een enkel stuk code, afhankelijk van de beller. Dat betekent vrijwel zeker dat er situaties zijn die je niet test of niet bedenkt waar je ontdekt dat je code iets onverwachts doet. Tussen het hebben van een heleboel status en het hebben van een codebasis met een heleboel bijwerkingen, kun je heel snel een codebasis bouwen die in wezen onhoudbaar is.