Useimmat tietokannan hallintajärjestelmät rajoittavat tarkistusrajoitukset koskemaan vain yhtä riviä, ja niillä on pääsy vakioihin ja deterministisiin funktioihin, mutta ei muissa taulukoissa oleviin tietoihin tai tietoihin, jotka ovat näkymättömiä nykyiselle transaktiolle transaktioiden eristämisen vuoksi.
Tämmöiset rajoitukset eivät ole todellisia taulun tarkistusrajoituksia vaan pikemminkin rivin tarkistusrajoituksia. Koska nämä rajoitukset tarkistetaan yleensä vain silloin, kun rivi päivitetään suoraan (suorituskykysyistä), ja koska ne on usein toteutettu implisiittisinä INSERT tai UPDATE-triggereinä, eheysrajoituksia voitaisiin rikkoa epäsuoralla toiminnalla, jos näitä rajoituksia ei olisi. Lisäksi CHECK-rajoitus estäisi muutoin pätevät muutokset näihin tietueisiin. Esimerkkejä vaarallisista rajoituksista ovat:
CHECK ((select count(*) from invoices where invoices.customerId = customerId) < 1000)CHECK (dateInserted = CURRENT_DATE)CHECK (countItems = RAND())
Käyttäjän määrittelemien laukaisimien avulla voidaan kiertää nämä rajoitukset. Vaikka toteutus on samankaltainen, on semanttisesti selvää, että laukaisimet laukeavat vain silloin, kun taulukkoa muutetaan suoraan, ja että on suunnittelijan vastuulla käsitellä epäsuorat, tärkeät muutokset muissa taulukoissa; rajoitusten sen sijaan on tarkoitus olla ”totta aina” riippumatta käyttäjän toimista tai suunnittelijan ennakoinnin puutteesta.