Sådan aktiveres alle CHECK &fremmednøglebegrænsninger i en database i SQL Server (T-SQL-eksempler)

Du kan bruge koden nedenfor til at aktivere alle CHECK og fremmednøgle begrænsninger for den aktuelle database i SQL Server.

Når du aktiverer en CHECK eller fremmednøglebegrænsning, har du mulighed for at kontrollere eksisterende data i tabellen, før begrænsningen aktiveres. Ved at gøre dette kan du kontrollere, om nogen eksisterende overtræder begrænsningen eller ej. For at udføre denne kontrol skal du bruge WITH CHECK i koden, ellers brug WITH NOCHECK .

Eksempelkode

Sådan aktiverer du alle CHECK og fremmednøgle-begrænsninger i en database. Det første eksempel kontrollerer eksisterende data, det andet gør ikke.

Med check (anbefales):

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

Uden check:

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

Du kan også udtrykkeligt angive argumentnavnet (@command1 ), hvis du foretrækker det (du får det samme resultat på begge måder).

Med Check:

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

Uden check:

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

Disse eksempler bruger den (udokumenterede) sp_MSforeachtable gemt procedure. Denne procedure giver dig mulighed for at udføre opgaver mod hver tabel i en database. Så det er perfekt til vores opgave her - at aktivere alle CHECK og fremmednøglebegrænsninger i den aktuelle database.

Nedenfor er et eksempel, hvor jeg gør dette og derefter tjekker resultatet.

Eksempel 1 – Gennemgå begrænsningerne

Først vil jeg tage et hurtigt kig på den aktuelle CHECK og fremmednøgle-begrænsninger i databasen for at se, om de er aktiveret eller deaktiveret.

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å der er i øjeblikket fire CHECK begrænsninger begrænsninger i databasen, for to forskellige tabeller.

Vi kan se, at alle begrænsninger er deaktiveret, fordi is_disabled er indstillet til 1 .

De er også alle upålidelige, fordi is_not_trusted er også indstillet til 1 .

Eksempel 2 – Aktiver begrænsningerne ved hjælp af MED KONTROL

Nu vil jeg aktivere alle begrænsninger ved hjælp af WITH CHECK argument:

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

Det er altid en god idé at sikre, at du bruger den korrekte database, når du gør denne type ting. Så vi kunne ændre koden ved først at skifte til den korrekte database:

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

I dette tilfælde skifter jeg til en database kaldet Test før den lagrede procedure udføres.

Eksempel 3 – Tjek resultatet

Efter at have kørt ovenstående kode, kører jeg nu den samme forespørgsel fra det første eksempel for at 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å alle begrænsninger i databasen er nu blevet aktiveret (fordi is_disabled kolonne er indstillet til 0 for alle begrænsninger).

Vi kan også se, at is_not_trusted kolonne er også indstillet til 0 . Det betyder, at der er tillid til begrænsningen. Det er betroet, fordi vi fik det til at kontrollere alle eksisterende data, før det blev aktiveret.

Hvis jeg havde brugt WITH NOCHECK , ville begrænsningerne forblive upålidelige (dvs. deres is_not_trusted flag ville blive sat til 1 ). Dette skyldes, at databasen potentielt kan indeholde data, der overtræder en (eller flere) af begrænsningerne (ugyldige data kunne være kommet ind i databasen, mens begrænsningerne var deaktiveret).

I sjældne tilfælde kan det være nødvendigt at opbevare ugyldige data i databasen. I sådanne tilfælde skal begrænsningen forblive upålidelig, fordi de eksisterende data ikke vil bestå den indledende kontrol, og begrænsningen vil derfor ikke være i stand til at blive aktiveret, medmindre den bruger WITH NOCHECK .

Se, hvad du bør vide om MED NOCHECK, når du aktiverer en CHECK-begrænsning i SQL Server for et detaljeret eksempel på skift mellem pålidelige og ikke-pålidelige, når du deaktiverer og genaktiverer en begrænsning.

Aktiver begrænsningerne individuelt

Hvis du kun ønsker at aktivere begrænsningerne én for én, se Sådan aktiverer du en CHECK-begrænsning i SQL Server og Sådan aktiverer du en fremmednøgle i SQL Server.