Anda dapat meminta pemicu di A melakukan sesuatu untuk memperingatkan pemicu di B bahwa pemicu tidak perlu diaktifkan. Ada berbagai keinginan untuk mengatur beberapa status untuk suatu sesi. Pendekatan paling sederhana yang mungkin adalah melakukan sesuatu seperti membuat paket dengan variabel boolean bypass_checks_on_b yang Anda setel ke TRUE sebelum Anda melakukan UPDATE pada A, setel ke FALSE setelah UPDATE selesai, lalu periksa status variabel ini di pemicu Anda di B sebelum melakukan validasi. Anda bisa melakukan sesuatu yang mirip dengan tabel sementara atau konteks juga daripada menggunakan paket. Kurang efisien, Anda berpotensi mengurai tumpukan panggilan di dalam pemicu Anda di B untuk melihat apakah pemicu di A ada di tumpukan panggilan tetapi itu cenderung agak jelek.
Saya akan sangat berhati-hati tentang seluruh arsitektur ini. Ketika Anda menemukan bahwa Anda memiliki pemicu pada A yang menyebabkan pemicu pada B menyala yang ingin menanyakan A, hampir selalu terjadi bahwa Anda telah memasukkan terlalu banyak logika dalam pemicu dan bahwa Anda akan jauh lebih baik dilayani bergerak logika itu ke dalam lapisan prosedur tersimpan yang dapat dipanggil daripada aplikasi yang melakukan penyisipan atau pembaruan langsung. Ketika Anda mendorong terlalu banyak logika ke pemicu, Anda berakhir dengan sistem yang sangat sulit untuk dipahami karena tidak jelas dari melihat kode aplikasi seperti apa efek samping dari berbagai pernyataan. Dan Anda berakhir dengan kode yang sangat stateful di mana Anda memiliki banyak jalur melalui satu bagian kode tergantung pada penelepon. Itu hampir pasti berarti bahwa akan ada status yang tidak Anda uji atau tidak memikirkan di mana Anda akan menemukan bahwa kode Anda melakukan sesuatu yang tidak terduga. Antara memiliki banyak status dan memiliki basis kode dengan banyak efek samping, Anda dapat dengan cepat membangun basis kode yang pada dasarnya tidak dapat dipertahankan.
