Om du har en CHECK begränsning i SQL Server som för närvarande är inaktiverad, kan du använda koden nedan för att återaktivera den.
När du aktiverar en CHECK begränsning (eller en främmande nyckel begränsning för den delen), har du möjlighet att ange om du vill kontrollera befintliga data i tabellen eller inte.
Nedan finns kodexempel för att aktivera en CHECK begränsning, samtidigt som du anger vart och ett av dessa olika alternativ.
Exempel 1 – Aktivera en begränsning med hjälp av MED KONTROLL
Detta är den rekommenderade metoden för att aktivera din CHECK begränsningar (såvida du inte har en specifik anledning att inte använda den).
Här är ett exempel på att aktivera en begränsning som heter chkJobTitle :
ALTER TABLE Occupation WITH CHECK CHECK CONSTRAINT chkJobTitle;
Här anger jag uttryckligen WITH CHECK , som säger åt SQL Server att kontrollera befintlig data innan begränsningen aktiveras. Om någon data bryter mot begränsningen kommer begränsningen inte att aktiveras och du får ett felmeddelande.
Detta är bra, eftersom det upprätthåller dataintegritet.
När du skapar en ny CHECK begränsning, detta är standardinställningen. Men när du aktiverar en befintlig begränsning (som vi gör här), är det inte standardinställningen.
Exempel 2 – Aktivera en begränsning med WITH NOCHECK
I det här exemplet är begränsningen aktiverad utan att kontrollera befintlig data:
ALTER TABLE Occupation WITH NOCHECK CHECK CONSTRAINT chkJobTitle;
Här anger jag uttryckligen WITH NOCHECK , som säger åt SQL Server att inte kontrollera befintliga data. Detta innebär att begränsningen kommer att aktiveras även om tabellen redan innehåller data som bryter mot begränsningen.
Detta är standardinställningen när du aktiverar en begränsning (men inte när du skapar en).
En av de få anledningarna (förmodligen den enda anledningen) du skulle använda detta är om du vill behålla ogiltiga data i databasen. Du kanske har ett engångsundantag där du måste ange en rad eller fler med ogiltiga data, men du kräver att all framtida data överensstämmer med begränsningen.
Det finns dock fortfarande risker med att göra detta. Här är vad Microsoft har att säga om detta:
Vi rekommenderar inte att du gör detta, förutom i sällsynta fall. Den nya begränsningen utvärderas i alla senare datauppdateringar. Alla begränsningsöverträdelser som undertrycks av
WITH NOCHECKNär begränsningen läggs till kan framtida uppdateringar misslyckas om de uppdaterar rader med data som inte följer begränsningen.
Så använder WITH NOCHECK kan eventuellt orsaka problem senare.
Exempel 3 – Aktivera en begränsning med hjälp av standardalternativet
Här är ett exempel med standardalternativet:
ALTER TABLE Occupation CHECK CONSTRAINT chkJobTitle;
Detta exempel är motsvarigheten till föregående exempel. Eftersom jag inte angav om jag skulle kontrollera eller inte, antar SQL Server att jag vill ha WITH NOCHECK .
Att använda WITH NOCHECK tar bort förtroende
När du aktiverar en begränsning med WITH NOCHECK , en konsekvens du bör vara medveten om är att SQL Server inte längre litar på den begränsningen. Den flaggar den som inte betrodd.
Ja du läste rätt. Det finns faktiskt en is_not_trusted flagga som SQL Server anger till 1 när du inaktiverar en CHECK begränsning (vilket betyder att den inte är betrodd), och det enda sättet att ställa in den på 0 (trusted) är att ange WITH CHECK när du återaktiverar begränsningen. Använder WITH NOCHECK klipper det bara inte.
Detta är helt vettigt. När allt kommer omkring, skulle du lita på en begränsning som inte har kontrollerat all data?
Genom att använda WITH CHECK , ser du till att begränsningen kontrollerar all befintlig data innan den aktiveras. Det enda sättet det kan aktiveras är om all befintlig data överensstämmer med begränsningen. När den har kontrollerat all befintlig data kan den litas på.
För mer om detta, se Vad du bör veta om MED NOCHECK när du aktiverar en CHECK-begränsning i SQL Server, där du kan se den faktiska is_not_trusted flaggan växlas fram och tillbaka varje gång jag inaktiverar och återaktiverar en CHECK begränsning.