Hvis du har en CHECK begrænsning i SQL Server, der i øjeblikket er deaktiveret, kan du bruge koden nedenfor til at genaktivere den.
Når du aktiverer en CHECK begrænsning (eller en fremmednøgle begrænsning for den sags skyld), har du mulighed for at angive, om du vil kontrollere eksisterende data i tabellen eller ej.
Nedenfor er kodeeksempler på aktivering af en CHECK begrænsning, mens du angiver hver af disse forskellige muligheder.
Eksempel 1 – Aktiver en begrænsning ved hjælp af MED KONTROL
Dette er den anbefalede metode til at aktivere din CHECK begrænsninger (medmindre du har en specifik grund til ikke at bruge det).
Her er et eksempel på aktivering af en begrænsning kaldet chkJobTitle :
ALTER TABLE Occupation WITH CHECK CHECK CONSTRAINT chkJobTitle;
Her angiver jeg udtrykkeligt WITH CHECK , som fortæller SQL Server at kontrollere de eksisterende data, før begrænsningen aktiveres. Hvis nogen data overtræder begrænsningen, vil begrænsningen ikke blive aktiveret, og du får en fejlmeddelelse.
Det er godt, fordi det håndhæver dataintegritet.
Når du opretter en ny CHECK begrænsning, dette er standardindstillingen. Men når du aktiverer en eksisterende begrænsning (som vi gør her), er det ikke standardindstillingen.
Eksempel 2 – Aktiver en begrænsning ved hjælp af MED NOCHECK
I dette eksempel er begrænsningen aktiveret uden at kontrollere de eksisterende data:
ALTER TABLE Occupation WITH NOCHECK CHECK CONSTRAINT chkJobTitle;
Her angiver jeg udtrykkeligt WITH NOCHECK , som fortæller SQL Server ikke at kontrollere de eksisterende data. Dette betyder, at begrænsningen vil blive aktiveret, selvom tabellen allerede indeholder data, der overtræder begrænsningen.
Dette er standardindstillingen, når du aktiverer en begrænsning (men ikke når du opretter en).
En af de få grunde (sandsynligvis den eneste grund) du ville bruge dette er, hvis du vil beholde ugyldige data i databasen. Måske har du en enkeltstående undtagelse, hvor du skal indtaste en række eller flere ugyldige data, men du kræver, at alle fremtidige data overholder begrænsningen.
Der er dog stadig risici forbundet med at gøre dette. Her er, hvad Microsoft har at sige om dette:
Vi anbefaler ikke at gøre dette, undtagen i sjældne tilfælde. Den nye begrænsning evalueres i alle senere dataopdateringer. Eventuelle overtrædelser af begrænsninger, der undertrykkes af WITH NOCHECK Når begrænsningen tilføjes, kan det medføre, at fremtidige opdateringer mislykkes, hvis de opdaterer rækker med data, der ikke følger begrænsningen.
Så ved at bruge WITH NOCHECK kan potentielt forårsage problemer senere.
Eksempel 3 – Aktiver en begrænsning ved hjælp af standardindstillingen
Her er et eksempel, der bruger standardindstillingen:
ALTER TABLE Occupation CHECK CONSTRAINT chkJobTitle;
Dette eksempel svarer til det foregående eksempel. Fordi jeg ikke specificerede, om jeg skulle kontrollere eller ej, antager SQL Server, at jeg vil have WITH NOCHECK .
Brug af WITH NOCHECK fjerner tillid
Når du aktiverer en begrænsning ved hjælp af WITH NOCHECK , en konsekvens du bør være opmærksom på er, at SQL Server ikke længere har tillid til denne begrænsning. Den markerer, at den ikke er betroet.
Ja du læste rigtigt. Der er faktisk en is_not_trusted flag, som SQL Server indstiller til 1 når du deaktiverer en CHECK begrænsning (hvilket betyder, at den ikke er tillid til), og den eneste måde at indstille den til 0 (trusted) er at angive WITH CHECK når du genaktiverer begrænsningen. Brug af WITH NOCHECK skærer det bare ikke.
Dette giver perfekt mening. Når alt kommer til alt, ville du stoler på en begrænsning, der ikke har kontrolleret alle data?
Ved at bruge WITH CHECK , sikrer du, at begrænsningen kontrollerer alle eksisterende data, før den aktiveres. Den eneste måde, det kan aktiveres på, er, hvis alle eksisterende data er i overensstemmelse med begrænsningen. Når den har kontrolleret alle eksisterende data, kan den stoles på.
For mere om dette, se Hvad du bør vide om MED NOCHECK, når du aktiverer en CHECK-begrænsning i SQL Server, hvor du kan se den faktiske is_not_trusted flag, der skiftes frem og tilbage, hver gang jeg deaktiverer og genaktiverer en CHECK begrænsning.