Możesz sprawić, by spust na A zrobił coś, aby ostrzec spust na B, że nie musi odpalić. Istnieje wiele chęci ustawienia jakiegoś stanu na sesję. Najprostszym możliwym podejściem byłoby zrobienie czegoś takiego jak utworzenie pakietu ze zmienną logiczną bypass_checks_on_b że ustawiłeś na TRUE przed wykonaniem UPDATE na A, ustaw na FALSE po UPDATE zakończy się, a następnie sprawdź stan tej zmiennej w wyzwalaczu na B przed wykonaniem walidacji. Możesz zrobić coś podobnego z tabelą tymczasową lub kontekstem, zamiast używać pakietu. Mniej wydajnie, możesz potencjalnie przeanalizować stos wywołań wewnątrz wyzwalacza na B, aby sprawdzić, czy wyzwalacz na A znajduje się w stosie wywołań, ale byłoby to raczej brzydkie.
Byłbym jednak bardzo ostrożny z całą tą architekturą. Kiedy odkryjesz, że masz wyzwalacze w A, które powodują uruchomienie wyzwalaczy w B, które chciałyby wysłać zapytanie A, prawie zawsze jest tak, że umieściłeś zbyt dużo logiki w wyzwalaczach i że znacznie lepiej będzie Ci się poruszać ta logika do warstwy procedury składowanej, która może być wywoływana, a nie aplikacje wykonujące bezpośrednie wstawienia lub aktualizacje. Kiedy wpychasz zbyt dużo logiki do wyzwalaczy, otrzymujesz system, który jest bardzo trudny do zrozumienia, ponieważ patrząc na kod aplikacji nie jest oczywiste, jakie skutki uboczne mają różne instrukcje. W rezultacie otrzymujesz bardzo stanowy kod, w którym masz wiele ścieżek przez jeden fragment kodu w zależności od wywołującego. To prawie na pewno oznacza, że pojawią się stany, których nie testujesz lub nie myślisz o tym, gdzie odkryjesz, że twój kod robi coś nieoczekiwanego. Pomiędzy posiadaniem tony stanu i posiadaniem bazy kodu z mnóstwem efektów ubocznych, bardzo szybko możesz zbudować bazę kodu, która jest zasadniczo nie do utrzymania.
