Si vous avez un CHECK contrainte dans SQL Server qui est actuellement désactivée, vous pouvez utiliser le code ci-dessous pour la réactiver.
Lorsque vous activez un CHECK contrainte (ou une contrainte de clé étrangère d'ailleurs), vous avez la possibilité de spécifier si vous souhaitez ou non vérifier les données existantes dans la table.
Vous trouverez ci-dessous des exemples de code d'activation d'un CHECK contrainte, en précisant chacune de ces différentes options.
Exemple 1 - Activer une contrainte à l'aide de WITH CHECK
Il s'agit de la méthode recommandée pour activer votre CHECK contraintes (sauf si vous avez une raison particulière de ne pas l'utiliser).
Voici un exemple d'activation d'une contrainte appelée chkJobTitle :
ALTER TABLE Occupation WITH CHECK CHECK CONSTRAINT chkJobTitle;
Ici, j'indique explicitement WITH CHECK , qui indique à SQL Server de vérifier les données existantes avant d'activer la contrainte. Si des données violent la contrainte, la contrainte ne sera pas activée et vous obtiendrez une erreur.
C'est bien, car cela renforce l'intégrité des données.
Lorsque vous créez un nouveau CHECK contrainte, il s'agit du paramètre par défaut. Cependant, lorsque vous activez une contrainte existante (comme nous le faisons ici), ce n'est pas le paramètre par défaut.
Exemple 2 - Activer une contrainte à l'aide de WITH NOCHECK
Dans cet exemple, la contrainte est activée sans vérifier les données existantes :
ALTER TABLE Occupation WITH NOCHECK CHECK CONSTRAINT chkJobTitle;
Ici, je déclare explicitement WITH NOCHECK , qui indique à SQL Server de ne pas vérifier les données existantes. Cela signifie que la contrainte sera activée même si la table contient déjà des données qui violent la contrainte.
Il s'agit du paramètre par défaut lors de l'activation d'une contrainte (mais pas lors de sa création).
L'une des rares raisons (probablement la seule raison) pour laquelle vous l'utiliseriez est si vous souhaitez conserver des données invalides dans la base de données. Vous avez peut-être une exception ponctuelle où vous devez entrer une ligne ou plus de données non valides, mais vous avez besoin que toutes les données futures soient conformes à la contrainte.
Cependant, il y a encore des risques associés à cela. Voici ce que Microsoft a à dire à ce sujet :
Nous vous déconseillons de le faire, sauf dans de rares cas. La nouvelle contrainte est évaluée dans toutes les mises à jour de données ultérieures. Toute violation de contrainte supprimée par
WITH NOCHECKlorsque la contrainte est ajoutée peut entraîner l'échec des futures mises à jour si elles mettent à jour des lignes avec des données qui ne respectent pas la contrainte.
Donc, en utilisant WITH NOCHECK pourrait potentiellement causer des problèmes plus tard.
Exemple 3 - Activer une contrainte à l'aide de l'option par défaut
Voici un exemple utilisant l'option par défaut :
ALTER TABLE Occupation CHECK CONSTRAINT chkJobTitle;
Cet exemple est l'équivalent de l'exemple précédent. Comme je n'ai pas précisé s'il fallait ou non vérifier, SQL Server suppose que je veux WITH NOCHECK .
L'utilisation de WITH NOCHECK supprime la confiance
Lorsque vous activez une contrainte à l'aide de WITH NOCHECK , une conséquence dont vous devez être conscient est que SQL Server ne fait plus confiance à cette contrainte. Il le signale comme non fiable.
Oui, tu l'as bien lu. Il y a en fait un is_not_trusted indicateur que SQL Server définit sur 1 lorsque vous désactivez un CHECK contrainte (ce qui signifie qu'elle n'est pas fiable) et la seule façon de la définir sur 0 (de confiance) est de spécifier WITH CHECK lors de la réactivation de la contrainte. Utilisation de WITH NOCHECK ne suffit pas.
Cela est parfaitement logique. Après tout, est-ce que vous faire confiance à une contrainte qui n'a pas vérifié toutes les données ?
En utilisant WITH CHECK , vous vous assurez que la contrainte vérifie toutes les données existantes avant son activation. La seule façon de l'activer est que toutes les données existantes soient conformes à la contrainte. Une fois qu'il a vérifié toutes les données existantes, on peut alors lui faire confiance.
Pour plus d'informations à ce sujet, consultez Ce que vous devez savoir sur WITH NOCHECK lors de l'activation d'une contrainte CHECK dans SQL Server, où vous pouvez voir le réel is_not_trusted le drapeau est basculé d'avant en arrière chaque fois que je désactive et réactive un CHECK contrainte.
