Většina systémů pro správu databází omezuje kontrolní omezení na jeden řádek s přístupem ke konstantám a deterministickým funkcím, nikoli však k datům v jiných tabulkách nebo k datům neviditelným pro aktuální transakci z důvodu izolace transakcí.
Taková omezení nejsou ve skutečnosti kontrolními omezeními tabulky, ale spíše kontrolními omezeními řádku. Protože tato omezení jsou obecně ověřována pouze při přímé aktualizaci řádku (z výkonnostních důvodů) a často jsou implementována jako implicitní INSERT nebo UPDATEspouštěče, mohla by být omezení integrity porušena nepřímou akcí, nebýt těchto omezení. Navíc by pak jinak platné úpravy těchto záznamů byly znemožněny omezením CHECK. Mezi příklady nebezpečných omezení patří:
CHECK ((select count(*) from invoices where invoices.customerId = customerId) < 1000)CHECK (dateInserted = CURRENT_DATE)CHECK (countItems = RAND())
Pro obejití těchto omezení lze použít spouštěče definované uživatelem. Ačkoli jsou implementačně podobné, je sémanticky jasné, že triggery se spustí pouze při přímé změně tabulky a že je odpovědností návrháře ošetřit nepřímé, důležité změny v jiných tabulkách; omezení naproti tomu mají být „vždy pravdivá“ bez ohledu na akce uživatele nebo nedostatek předvídavosti návrháře.