Vous pouvez utiliser le code ci-dessous pour activer tous les CHECK
et les contraintes de clé étrangère pour une table spécifique dans SQL Server.
Lorsque vous activez une contrainte dans SQL Server, vous devez décider si elle doit vérifier ou non les données existantes. Il s'agit d'une considération importante si la table contient déjà des données, car ces données existantes peuvent potentiellement enfreindre les règles de la contrainte.
Exemples de déclarations
Vous trouverez ci-dessous deux exemples d'instructions qui montrent la différence entre vérifier les données existantes et ne pas les vérifier lorsque vous activez les contraintes.
Pour vérifier les données existantes, utilisez WITH CHECK
dans votre déclaration lors de l'activation des contraintes, sinon utilisez WITH NOCHECK
.
Avec Chèque :
ALTER TABLE TableName WITH CHECK CHECK CONSTRAINT ALL
Sans chèque :
ALTER TABLE TableName WITH NOCHECK CHECK CONSTRAINT ALL
Remplacez simplement TableName
avec le nom de la table applicable.
Voici un exemple où je fais cela et vérifie les résultats.
Exemple 1 - Examiner les contraintes
Tout d'abord, je vais jeter un coup d'œil au CHECK
actuel contraintes dans la base de données, pour voir si oui ou non elles sont activées ou désactivées.
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;
Résultat :
+----------------+-----------------+---------------+------------------+ | Table | Constraint | is_disabled | is_not_trusted | |----------------+-----------------+---------------+------------------| | ConstraintTest | chkPrice | 1 | 1 | | ConstraintTest | chkValidEndDate | 1 | 1 | | ConstraintTest | chkTeamSize | 1 | 1 | | Occupation | chkJobTitle | 0 | 0 | +----------------+-----------------+---------------+------------------+
Il y a donc actuellement quatre CHECK
contraintes dans la base de données, dont trois pour le ConstraintTest
tableau.
Nous pouvons voir que toutes les contraintes de la table sont désactivées car is_disabled est défini sur 1 .
Nous pouvons également voir que le is_not_trusted la colonne est définie sur 1 pour ces contraintes. Cela signifie qu'ils ne sont pas dignes de confiance. On ne peut pas leur faire confiance tant qu'ils sont désactivés, car des données non valides peuvent entrer dans la base de données sans être vérifiées. Plus d'informations ci-dessous.
L'autre contrainte (pour une autre table) est déjà activée et approuvée (mais nous pouvons ignorer cette table/contrainte dans cet article).
Exemple 2 - Activer les contraintes à l'aide de WITH CHECK
Maintenant, je vais activer toutes les contraintes pour le ConstraintTest
tableau :
ALTER TABLE ConstraintTest WITH CHECK CHECK CONSTRAINT ALL;
Voilà, c'est fait.
Exécutons maintenant la même requête du premier exemple pour voir le résultat.
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;
Résultat :
+----------------+-----------------+---------------+------------------+ | Table | Constraint | is_disabled | is_not_trusted | |----------------+-----------------+---------------+------------------| | ConstraintTest | chkPrice | 0 | 0 | | ConstraintTest | chkValidEndDate | 0 | 0 | | ConstraintTest | chkTeamSize | 0 | 0 | | Occupation | chkJobTitle | 0 | 0 | +----------------+-----------------+---------------+------------------+
Les trois contraintes pour le ConstraintTest table sont maintenant activés et approuvés.
Ils sont dignes de confiance car j'ai utilisé WITH CHECK
dans ma déclaration. Si je ne l'avais pas fait, j'aurais obtenu un résultat différent, comme vous le verrez ci-dessous.
En utilisant WITH CHECK
, je peux être sûr que toutes les données existantes dans la table sont en fait conformes aux contraintes.
Exemple 3 - Activer les contraintes à l'aide de WITH NOCHECK
Maintenant, je vais réactiver les contraintes en utilisant WITH CHECK
afin que nous puissions voir comment cela affecte le résultat.
Mais je dois d'abord les désactiver :
ALTER TABLE ConstraintTest NOCHECK CONSTRAINT ALL;
Vérifiez qu'ils sont désactivés :
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;
Résultat :
+----------------+-----------------+---------------+------------------+ | Table | Constraint | is_disabled | is_not_trusted | |----------------+-----------------+---------------+------------------| | ConstraintTest | chkPrice | 1 | 1 | | ConstraintTest | chkValidEndDate | 1 | 1 | | ConstraintTest | chkTeamSize | 1 | 1 | | Occupation | chkJobTitle | 0 | 0 | +----------------+-----------------+---------------+------------------+
Ils sont donc à nouveau désactivés.
Maintenant, réactivez-les en utilisant WITH NOCHECK
:
ALTER TABLE ConstraintTest WITH NOCHECK CHECK CONSTRAINT ALL;
Vérifiez à nouveau :
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;
Résultat :
+----------------+-----------------+---------------+------------------+ | Table | Constraint | is_disabled | is_not_trusted | |----------------+-----------------+---------------+------------------| | ConstraintTest | chkPrice | 0 | 1 | | ConstraintTest | chkValidEndDate | 0 | 1 | | ConstraintTest | chkTeamSize | 0 | 1 | | Occupation | chkJobTitle | 0 | 0 | +----------------+-----------------+---------------+------------------+
Nous pouvons voir que les contraintes ont été activées avec succès, mais cette fois, elles restent non fiables.
Les contraintes ne sont pas fiables car elles n'ont vérifié aucune donnée existante avant d'être activées.
Donc, la clé à retenir ici est que si vous voulez que vos contraintes soient fiables, assurez-vous d'utiliser WITH CHECK
lors de leur activation.
Activer les contraintes individuellement
Si vous ne souhaitez pas activer toutes les contraintes à la fois, vous pouvez les activer individuellement. Cela peut également être utile si vous devez activer toutes les contraintes, mais que vous devez utiliser des paramètres différents (par exemple, WITH CHECK
pour certains et WITH NOCHECK
pour les autres).
Voir Comment activer une contrainte CHECK dans SQL Server et Comment activer une clé étrangère dans SQL Server.