De fleste databaseadministrationssystemer begrænser kontrolbegrænsninger til en enkelt række med adgang til konstanter og deterministiske funktioner, men ikke til data i andre tabeller eller til data, der er usynlige for den aktuelle transaktion på grund af transaktionsisolering.
Disse begrænsninger er ikke egentlige tabelkontrolbegrænsninger, men snarere rækkekontrolbegrænsninger. Da disse begrænsninger generelt kun verificeres, når en række opdateres direkte (af ydelsesmæssige årsager) og ofte implementeres som implicitte INSERT eller UPDATE triggers, kunne integritetsbegrænsninger overtrædes ved indirekte handling, hvis det ikke var for disse begrænsninger. Desuden ville ellers gyldige ændringer af disse poster i så fald blive forhindret af CHECK-begrænsningen. Nogle eksempler på farlige begrænsninger omfatter:
CHECK ((select count(*) from invoices where invoices.customerId = customerId) < 1000)CHECK (dateInserted = CURRENT_DATE)CHECK (countItems = RAND())
Brugerdefinerede udløsere kan bruges til at omgå disse begrænsninger. Selv om de ligner hinanden i implementeringen, er det semantisk klart, at triggere kun udløses, når tabellen ændres direkte, og at det er designerens ansvar at håndtere indirekte, vigtige ændringer i andre tabeller; begrænsninger på den anden side er beregnet til at være “sande til enhver tid” uanset brugerens handlinger eller designerens manglende forudseenhed.