Hoe u alle beperkingen van CHECK en externe sleutels in een database in SQL Server inschakelt (T-SQL-voorbeelden)

U kunt de onderstaande code gebruiken om alle CHECK . in te schakelen en externe sleutelbeperkingen voor de huidige database in SQL Server.

Wanneer u een CHECK . inschakelt of externe sleutelbeperking, hebt u de mogelijkheid om bestaande gegevens in de tabel te controleren voordat de beperking wordt ingeschakeld. Als u dit doet, kunt u controleren of bestaande al dan niet de beperking schendt. Om deze controle uit te voeren, gebruikt u WITH CHECK binnen de code, gebruik anders WITH NOCHECK .

Voorbeeldcode

Hier leest u hoe u alle CHECK . inschakelt en externe sleutelbeperkingen binnen een database. Het eerste voorbeeld controleert bestaande gegevens, het tweede niet.

Met cheque (aanbevolen):

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

Zonder cheque:

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

U kunt ook expliciet de argumentnaam opgeven (@command1 ) als je wilt (je krijgt hoe dan ook hetzelfde resultaat).

Met cheque:

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

Zonder cheque:

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

Deze voorbeelden gebruiken de (ongedocumenteerde) sp_MSforeachtable opgeslagen procedure. Met deze procedure kunt u taken uitvoeren voor elke tabel in een database. Het is dus perfect voor onze taak hier - om alle CHECK . in te schakelen en externe sleutelbeperkingen binnen de huidige database.

Hieronder ziet u een voorbeeld waarin ik dit doe en vervolgens het resultaat controleer.

Voorbeeld 1 – Bekijk de beperkingen

Ik zal eerst even kijken naar de huidige CHECK en externe sleutelbeperkingen in de database, om te zien of ze al dan niet zijn ingeschakeld of uitgeschakeld.

SELECT OBJECT_NAME(parent_object_id) AS 'Table', naam AS 'Constraint', is_disabled, is_not_trustedFROM sys.foreign_keysUNIONSELECT OBJECT_NAME(parent_object_id), name, is_disabled, is_not_trustedFROM sys.check_constraint;
 Resultaat:
 
+----------------+-----------------+----------- ----+------------------+| Tafel | beperking | is_disabled | is_not_trusted ||----------------+-----------------+------------ ---+------------------|| BeperkingTest | chkPrijs | 1 | 1 || BeperkingTest | chkValidEndDate | 1 | 1 || BeperkingTest | chkTeamSize | 1 | 1 || beroep | chkJobTitel | 1 | 1 |+----------------+-----------------+------------ ---+------------------+
 

 Er zijn dus momenteel vier CHECK beperkingen beperkingen in de database, voor twee verschillende tabellen.
 

 We kunnen zien dat alle beperkingen zijn uitgeschakeld, omdat 
is_disabled
 is ingesteld op 
1
 .
 

 Ze zijn ook allemaal niet vertrouwd, omdat 
is_not_trusted
 is ook ingesteld op 
1
 .
 
Voorbeeld 2 – Schakel de beperkingen in met WITH CHECK
 

 Nu zal ik alle beperkingen inschakelen met behulp van de WITH CHECK argument:
 
EXEC sp_MSforeachtable "ALTER TABLE ? WITH CHECK CONTROL CONSTRAINT ALL"
 

 Het is altijd een goed idee om ervoor te zorgen dat u de juiste database gebruikt wanneer u dit soort dingen doet. Dus we konden de code aanpassen door eerst naar de juiste database te gaan:
 
GEBRUIK Test;EXEC sp_MSforeachtable "ALTER TABLE ? WITH CHECK CONTROL CONSTRAINT ALL"
 

 In dit geval schakel ik over naar een database genaamd 
Test
 voordat u de opgeslagen procedure uitvoert.
 
Voorbeeld 3 – Controleer het resultaat
 

 Nadat ik de bovenstaande code heb uitgevoerd, voer ik nu dezelfde query uit als in het eerste voorbeeld om het resultaat te zien.
 
SELECT OBJECT_NAME(parent_object_id) AS 'Table', naam AS 'Constraint', is_disabled, is_not_trustedFROM sys.foreign_keysUNIONSELECT OBJECT_NAME(parent_object_id), name, is_disabled, is_not_trustedFROM sys.check_constraint;
 Resultaat:
 
+----------------+-----------------+----------- ----+------------------+| Tafel | beperking | is_disabled | is_not_trusted ||----------------+-----------------+------------ ---+------------------|| BeperkingTest | chkPrijs | 0 | 0 || BeperkingTest | chkValidEndDate | 0 | 0 || BeperkingTest | chkTeamSize | 0 | 0 || beroep | chkJobTitel | 0 | 0 |+----------------+-----------------+------------ ---+------------------+
 

 Dus alle beperkingen in de database zijn nu ingeschakeld (omdat de 
is_disabled
 kolom is ingesteld op 
0
 voor alle beperkingen).
 

 We kunnen ook zien dat de 
is_not_trusted
 kolom is ook ingesteld op 
0
 . Dit betekent dat de beperking wordt vertrouwd. Het is vertrouwd, omdat we het alle bestaande gegevens hebben laten controleren voordat het wordt ingeschakeld.
 

 Als ik WITH NOCHECK . had gebruikt , zouden de beperkingen niet vertrouwd blijven (d.w.z. hun 
is_not_trusted
 vlag zou worden ingesteld op 
1
 ). Dit komt omdat de database mogelijk gegevens kan bevatten die een (of meer) van de beperkingen schenden (ongeldige gegevens kunnen de database zijn binnengekomen terwijl de beperkingen waren uitgeschakeld).
 

 In zeldzame gevallen moet u mogelijk ongeldige gegevens in de database bewaren. In dergelijke gevallen moet de beperking niet-vertrouwd blijven, omdat de bestaande gegevens de eerste controle niet zouden doorstaan ​​en daarom zou de beperking niet kunnen worden ingeschakeld tenzij het gebruik maakt van WITH NOCHECK .
 

 Zie Wat u moet weten over WITH NOCHECK bij het inschakelen van een CHECK-beperking in SQL Server voor een gedetailleerd voorbeeld van schakelen tussen vertrouwd en niet-vertrouwd bij het uitschakelen en opnieuw inschakelen van een beperking.
 
Schakel de beperkingen afzonderlijk in
 

 Als u de beperkingen alleen één voor één wilt inschakelen, raadpleegt u Een CONTROLE-beperking inschakelen in SQL Server en Een externe sleutel inschakelen in SQL Server.