Als u een CHECK
. heeft beperking in SQL Server die momenteel is uitgeschakeld, kunt u de onderstaande code gebruiken om deze weer in te schakelen.
Wanneer u een CHECK
. inschakelt beperking (of een beperking voor een externe sleutel), hebt u de mogelijkheid om aan te geven of u al dan niet bestaande gegevens in de tabel wilt controleren.
Hieronder staan codevoorbeelden voor het inschakelen van een CHECK
beperking, terwijl u elk van deze verschillende opties specificeert.
Voorbeeld 1 – Schakel een beperking in met WITH CHECK
Dit is de aanbevolen methode om uw CHECK
. in te schakelen beperkingen (tenzij je een specifieke reden hebt om het niet te gebruiken).
Hier is een voorbeeld van het inschakelen van een beperking met de naam chkJobTitle
:
ALTER TABLE Occupation WITH CHECK CHECK CONSTRAINT chkJobTitle;
Hier vermeld ik expliciet WITH CHECK
, die SQL Server vertelt om de bestaande gegevens te controleren voordat de beperking wordt ingeschakeld. Als gegevens de beperking schenden, wordt de beperking niet ingeschakeld en krijgt u een foutmelding.
Dit is goed, omdat het de gegevensintegriteit afdwingt.
Wanneer u een nieuwe CHECK
. aanmaakt beperking, dit is de standaardinstelling. Wanneer u echter een bestaande beperking inschakelt (zoals we hier doen), is dit niet de standaardinstelling.
Voorbeeld 2 – Schakel een beperking in met WITH NOCHECK
In dit voorbeeld is de beperking ingeschakeld zonder de bestaande gegevens te controleren:
ALTER TABLE Occupation WITH NOCHECK CHECK CONSTRAINT chkJobTitle;
Hier vermeld ik expliciet WITH NOCHECK
, die SQL Server vertelt om de bestaande gegevens niet te controleren. Dit betekent dat de beperking wordt ingeschakeld, zelfs als de tabel al gegevens bevat die de beperking schenden.
Dit is de standaardinstelling bij het inschakelen van een beperking (maar niet bij het maken ervan).
Een van de weinige redenen (waarschijnlijk de enige reden) dat u dit zou gebruiken, is als u ongeldige gegevens in de database wilt behouden. Misschien heeft u een eenmalige uitzondering waarbij u een rij of meer ongeldige gegevens moet invoeren, maar u wilt dat alle toekomstige gegevens aan de beperking voldoen.
Er zijn echter nog steeds risico's verbonden aan het doen hiervan. Dit is wat Microsoft hierover te zeggen heeft:
We raden af om dit te doen, behalve in zeldzame gevallen. De nieuwe beperking wordt geëvalueerd in alle latere gegevensupdates. Alle beperkingsschendingen die worden onderdrukt door
WITH NOCHECK
wanneer de beperking wordt toegevoegd, kunnen toekomstige updates mislukken als ze rijen bijwerken met gegevens die niet aan de beperking voldoen.
Dus gebruik WITH NOCHECK
kan later mogelijk problemen veroorzaken.
Voorbeeld 3 – Schakel een beperking in met de standaardoptie
Hier is een voorbeeld met de standaardoptie:
ALTER TABLE Occupation CHECK CONSTRAINT chkJobTitle;
Dit voorbeeld is het equivalent van het vorige voorbeeld. Omdat ik niet heb aangegeven of ik wel of niet moet controleren, gaat SQL Server ervan uit dat ik WITH NOCHECK
wil .
Gebruik WITH NOCHECK verwijdert vertrouwen
Wanneer u een beperking inschakelt met WITH NOCHECK
, is een gevolg waarvan u zich bewust moet zijn dat SQL Server die beperking niet langer vertrouwt. Het markeert het als niet vertrouwd.
Ja je leest het goed. Er is eigenlijk een is_not_trusted
vlag die SQL Server instelt op 1
wanneer u een CHECK
. uitschakelt beperking (wat betekent dat het niet vertrouwd is), en de enige manier om het in te stellen op 0
(vertrouwd) is om WITH CHECK
op te geven wanneer u de beperking opnieuw inschakelt. Gebruik WITH NOCHECK
snijdt het gewoon niet.
Dit is volkomen logisch. Per slot van rekening zou je een beperking vertrouwen die niet alle gegevens heeft gecontroleerd?
Door WITH CHECK
. te gebruiken , zorgt u ervoor dat de beperking alle bestaande gegevens controleert voordat deze wordt ingeschakeld. De enige manier waarop het kan worden ingeschakeld, is als alle bestaande gegevens voldoen aan de beperking. Zodra het alle bestaande gegevens heeft gecontroleerd, kan het worden vertrouwd.
Zie voor meer informatie Wat u moet weten over WITH NOCHECK bij het inschakelen van een CHECK-beperking in SQL Server, waar u de werkelijke is_not_trusted
kunt zien. vlag wordt heen en weer geschakeld elke keer dat ik een CHECK
in- en uitschakel beperking.