Vous pouvez utiliser le code ci-dessous pour activer tous les CHECK et contraintes de clé étrangère pour la base de données actuelle dans SQL Server.
Lorsque vous activez un CHECK ou contrainte de clé étrangère, vous avez la possibilité de vérifier les données existantes dans la table avant que la contrainte ne soit activée. Cela vous permet de vérifier si un élément existant viole ou non la contrainte. Pour effectuer cette vérification, utilisez WITH CHECK dans le code, sinon utilisez WITH NOCHECK .
Exemple de code
Voici comment activer tous les CHECK et les contraintes de clé étrangère dans une base de données. Le premier exemple vérifie les données existantes, le second non.
Avec chèque (recommandé) :
EXEC sp_MSforeachtable "ALTER TABLE ? WITH CHECK CHECK CONSTRAINT ALL"
Sans chèque :
EXEC sp_MSforeachtable "ALTER TABLE ? WITH NOCHECK CHECK CONSTRAINT ALL"
Vous pouvez également fournir explicitement le nom de l'argument (@command1 ) si vous préférez (vous obtiendrez le même résultat de toute façon).
Avec Chèque :
EXEC sp_MSforeachtable @command1="ALTER TABLE ? WITH CHECK CHECK CONSTRAINT ALL"
Sans chèque :
EXEC sp_MSforeachtable @command1="ALTER TABLE ? WITH CHECK CHECK CONSTRAINT ALL"
Ces exemples utilisent le (non documenté) sp_MSforeachtable procédure stockée. Cette procédure vous permet d'effectuer des tâches sur chaque table d'une base de données. C'est donc parfait pour notre tâche ici - pour activer tous les CHECK et les contraintes de clé étrangère dans la base de données actuelle.
Vous trouverez ci-dessous un exemple où je fais cela, puis je vérifie le résultat.
Exemple 1 - Examiner les contraintes
Tout d'abord, je vais jeter un coup d'œil au CHECK actuel et les contraintes de clé étrangère dans la base de données, pour voir si 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 | 1 | 1 | +----------------+-----------------+---------------+------------------+
Il y a donc actuellement quatre CHECK contraintes contraintes dans la base de données, pour deux tables différentes.
Nous pouvons voir que toutes les contraintes sont désactivées, car is_disabled est défini sur 1 .
De plus, ils ne sont pas tous fiables, car is_not_trusted est également défini sur 1 .
Exemple 2 - Activer les contraintes à l'aide de WITH CHECK
Maintenant, je vais activer toutes les contraintes en utilisant le WITH CHECK argument :
EXEC sp_MSforeachtable "ALTER TABLE ? WITH CHECK CHECK CONSTRAINT ALL"
C'est toujours une bonne idée de s'assurer que vous utilisez la bonne base de données lorsque vous faites ce genre de chose. Nous pourrions donc modifier le code en passant d'abord à la bonne base de données :
USE Test; EXEC sp_MSforeachtable "ALTER TABLE ? WITH CHECK CHECK CONSTRAINT ALL"
Dans ce cas, je passe à une base de données appelée Test avant d'exécuter la procédure stockée.
Exemple 3 - Vérifier le résultat
Après avoir exécuté le code ci-dessus, je vais maintenant exécuter 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 | +----------------+-----------------+---------------+------------------+
Ainsi, toutes les contraintes de la base de données ont maintenant été activées (parce que is_disabled la colonne est définie sur 0 pour toutes les contraintes).
Nous pouvons également voir que le is_not_trusted la colonne est également définie sur 0 . Cela signifie que la contrainte est fiable. Il est fiable, car nous l'avons fait vérifier toutes les données existantes avant d'être activé.
Si j'avais utilisé WITH NOCHECK , les contraintes resteraient non fiables (c'est-à-dire que leur
is_not_trusted
flag serait défini sur
1
). En effet, la base de données pourrait potentiellement contenir des données qui enfreignent une (ou plusieurs) des contraintes (des données non valides auraient pu entrer dans la base de données alors que les contraintes étaient désactivées).
En de rares occasions, vous devrez peut-être conserver des données non valides dans la base de données. Dans de tels cas, la contrainte devra rester non fiable, car les données existantes ne passeraient pas la vérification initiale et, par conséquent, la contrainte ne pourrait pas être activée à moins qu'elle n'utilise WITH NOCHECK .
Consultez Ce que vous devez savoir sur WITH NOCHECK lors de l'activation d'une contrainte CHECK dans SQL Server pour un exemple détaillé de basculement entre fiable et non fiable lors de la désactivation et de la réactivation d'une contrainte.
Activer les contraintes individuellement
Si vous souhaitez uniquement activer les contraintes une par une, consultez Comment activer une contrainte CHECK dans SQL Server et Comment activer une clé étrangère dans SQL Server.
