Můžete nechat spoušť na A udělat něco, aby upozornila spoušť na B, že nemusí střílet. Existují různé požadavky na nastavení určitého stavu pro relaci. Nejjednodušší možný přístup by bylo udělat něco jako vytvoření balíčku s booleovskou proměnnou bypass_checks_on_b kterou nastavíte na TRUE než provedete UPDATE na A nastavte na FALSE jednou UPDATE dokončí a poté před provedením ověření zkontrolujte stav této proměnné ve vašem spouštěči na B. Něco podobného byste mohli udělat s dočasnou tabulkou nebo kontextem, spíše než pomocí balíčku. Méně efektivně byste mohli potenciálně analyzovat zásobník volání uvnitř spouštěče na B, abyste zjistili, zda je spouštěč na A v zásobníku volání, ale to by bylo spíše ošklivé.
S celou touto architekturou bych byl ale velmi opatrný. Když zjistíte, že máte na A spouštěče, které způsobují spouštění spouštěčů na B, které by se chtěly dotazovat A, je téměř vždy případ, že jste do spouštěčů vložili příliš mnoho logiky a že by vám mnohem lépe posloužilo přesunutí. tuto logiku do vrstvy uložené procedury, kterou lze volat spíše než aplikace provádějící přímé vkládání nebo aktualizace. Když do spouštěčů vložíte příliš mnoho logiky, skončíte se systémem, kterému je velmi obtížné porozumět, protože při pohledu na kód aplikace není zřejmé, jaké vedlejší účinky různé příkazy mají. A skončíte s velmi stavovým kódem, kde máte mnoho cest přes jediný kus kódu v závislosti na volajícím. To téměř jistě znamená, že nastanou stavy, které netestujete nebo nemyslíte na to, kde zjistíte, že váš kód dělá něco neočekávaného. Mezi tím, že máte spoustu stavu a máte kódovou základnu se spoustou vedlejších účinků, můžete velmi rychle vytvořit kódovou základnu, která je v podstatě neudržitelná.