Hur man aktiverar alla begränsningar för kontroll och främmande nyckel i en databas i SQL Server (T-SQL-exempel)

Du kan använda koden nedan för att aktivera alla CHECK och främmande nyckelbegränsningar för den aktuella databasen i SQL Server.

När du aktiverar en CHECK eller främmande nyckel-begränsning, har du möjlighet att kontrollera befintliga data i tabellen innan begränsningen aktiveras. Genom att göra detta kan du verifiera om någon befintlig bryter mot begränsningen eller inte. För att utföra denna kontroll, använd WITH CHECK i koden, annars använd WITH NOCHECK .

Exempelkod

Så här aktiverar du alla CHECK och främmande nyckelbegränsningar i en databas. Det första exemplet kontrollerar befintlig data, det andra gör det inte.

Med bock (rekommenderas):

EXEC sp_MSforeachtable "ALTER TABLE ? WITH CHECK CHECK CONSTRAINT ALL"

Utan kontroll:

EXEC sp_MSforeachtable "ALTER TABLE ? WITH NOCHECK CHECK CONSTRAINT ALL"

Du kan också uttryckligen ange argumentnamnet (@command1 ) om du föredrar det (du får samma resultat i båda fallen).

Med Check:

EXEC sp_MSforeachtable @command1="ALTER TABLE ? WITH CHECK CHECK CONSTRAINT ALL"

Utan kontroll:

EXEC sp_MSforeachtable @command1="ALTER TABLE ? WITH CHECK CHECK CONSTRAINT ALL"

Dessa exempel använder den (odokumenterade) sp_MSforeachtable lagrad procedur. Denna procedur låter dig utföra uppgifter mot varje tabell i en databas. Så det är perfekt för vår uppgift här – att aktivera alla CHECK och främmande nyckelbegränsningar i den aktuella databasen.

Nedan är ett exempel där jag gör detta och sedan kontrollerar resultatet.

Exempel 1 – Granska begränsningarna

Först ska jag ta en snabb titt på den nuvarande CHECK och främmande nyckelbegränsningar i databasen, för att se om de är aktiverade eller inaktiverade.

SELECT
  OBJECT_NAME(parent_object_id) AS 'Table',
  name AS 'Constraint',
  is_disabled, 
  is_not_trusted
FROM sys.foreign_keys
UNION
SELECT 
  OBJECT_NAME(parent_object_id),
  name,
  is_disabled, 
  is_not_trusted
FROM sys.check_constraints;

Resultat:

+----------------+-----------------+---------------+------------------+
| Table          | Constraint      | is_disabled   | is_not_trusted   |
|----------------+-----------------+---------------+------------------|
| ConstraintTest | chkPrice        | 1             | 1                |
| ConstraintTest | chkValidEndDate | 1             | 1                |
| ConstraintTest | chkTeamSize     | 1             | 1                |
| Occupation     | chkJobTitle     | 1             | 1                |
+----------------+-----------------+---------------+------------------+

Så det finns för närvarande fyra CHECK begränsningar begränsningar i databasen, för två olika tabeller.

Vi kan se att alla begränsningar är inaktiverade eftersom is_disabled är inställd på 1 .

Dessutom är de alla opålitliga, eftersom är_inte_tillförlitlig är också inställd på 1 .

Exempel 2 – Aktivera begränsningarna med MED KONTROLL

Nu kommer jag att aktivera alla begränsningar med hjälp av WITH CHECK argument:

EXEC sp_MSforeachtable "ALTER TABLE ? WITH CHECK CHECK CONSTRAINT ALL"

Det är alltid en bra idé att se till att du använder rätt databas när du gör den här typen av saker. Så vi kunde ändra koden genom att först byta till rätt databas:

USE Test;
EXEC sp_MSforeachtable "ALTER TABLE ? WITH CHECK CHECK CONSTRAINT ALL"

I det här fallet byter jag till en databas som heter Test innan den lagrade proceduren utförs.

Exempel 3 – Kontrollera resultatet

Efter att ha kört ovanstående kod kör jag nu samma fråga från det första exemplet för att se resultatet.

SELECT
  OBJECT_NAME(parent_object_id) AS 'Table',
  name AS 'Constraint',
  is_disabled, 
  is_not_trusted
FROM sys.foreign_keys
UNION
SELECT 
  OBJECT_NAME(parent_object_id),
  name,
  is_disabled, 
  is_not_trusted
FROM sys.check_constraints;

Resultat:

+----------------+-----------------+---------------+------------------+
| Table          | Constraint      | is_disabled   | is_not_trusted   |
|----------------+-----------------+---------------+------------------|
| ConstraintTest | chkPrice        | 0             | 0                |
| ConstraintTest | chkValidEndDate | 0             | 0                |
| ConstraintTest | chkTeamSize     | 0             | 0                |
| Occupation     | chkJobTitle     | 0             | 0                |
+----------------+-----------------+---------------+------------------+

Så alla begränsningar i databasen har nu aktiverats (eftersom is_disabled kolumnen är inställd på 0 för alla begränsningar).

Vi kan också se att is_not_trusted kolumnen är också inställd på 0 . Detta betyder att begränsningen är pålitlig. Den är betrodd, eftersom vi fick den att kontrollera all befintlig data innan den aktiveras.

Om jag hade använt WITH NOCHECK , skulle begränsningarna förbli opålitliga (dvs. deras is_not_trusted flaggan skulle sättas till 1 ). Detta beror på att databasen potentiellt kan innehålla data som bryter mot en (eller flera) av begränsningarna (ogiltig data kan ha kommit in i databasen medan begränsningarna var inaktiverade).

I sällsynta fall kan du behöva behålla ogiltiga data i databasen. I sådana fall kommer begränsningen att behöva förbli opålitlig, eftersom befintlig data inte skulle klara den första kontrollen och därför skulle begränsningen inte kunna aktiveras om den inte använder WITH NOCHECK .

Se Vad du bör veta om MED NOCHECK när du aktiverar en CHECK-begränsning i SQL Server för ett detaljerat exempel på hur du växlar mellan betrodd och otillförlitlig när du inaktiverar och återaktiverar en begränsning.

Aktivera begränsningarna individuellt

Om du bara vill aktivera begränsningarna en i taget, se Hur man aktiverar en CHECK-begränsning i SQL Server och Hur man aktiverar en främmande nyckel i SQL Server.