CHECKがある場合 現在無効になっているSQLServerの制約については、以下のコードを使用して再度有効にすることができます。
CHECKを有効にした場合 制約（またはそのことについては外部キー制約）には、テーブル内の既存のデータをチェックするかどうかを指定するオプションがあります。
以下は、CHECKを有効にするコード例です。 これらの異なるオプションのそれぞれを指定しながら、制約。
例1-WITHCHECKを使用して制約を有効にする
これは、CHECKを有効にするための推奨される方法です。 制約（使用しない特別な理由がない限り）
chkJobTitleという制約を有効にする例を次に示します。 ：
ALTER TABLE Occupation WITH CHECK CHECK CONSTRAINT chkJobTitle;
ここでは、WITH CHECKを明示的に述べています 、これは、制約を有効にする前に既存のデータをチェックするようにSQLServerに指示します。いずれかのデータが制約に違反している場合、制約は有効にならず、エラーが発生します。
これは、データの整合性を強制するため、優れています。
新しいCHECKを作成するとき 制約、これはデフォルト設定です。ただし、既存の制約を有効にすると（ここで行っているように）、ではありません。 デフォルト設定。
例2–WITHNOCHECKを使用して制約を有効にする
この例では、既存のデータをチェックせずに制約を有効にします。
ALTER TABLE Occupation WITH NOCHECK CHECK CONSTRAINT chkJobTitle;
ここでは、WITH NOCHECKを明示的に述べています 、SQLServerに既存のデータをチェックしないように指示します。これは、テーブルに制約に違反するデータがすでに含まれている場合でも、制約が有効になることを意味します。
これは、制約を有効にする場合のデフォルト設定です（ただし、制約を作成する場合はデフォルト設定ではありません）。
これを使用するいくつかの理由の1つ（おそらく唯一の理由）は、データベースに無効なデータを保持したい場合です。おそらく、1行以上の無効なデータを入力する必要があるが、将来のすべてのデータが制約に準拠する必要があるという1回限りの例外があります。
ただし、これを行うことに関連するリスクはまだあります。これについてMicrosoftが言わなければならないことは次のとおりです。
まれな場合を除いて、これを行うことはお勧めしません。新しい制約は、それ以降のすべてのデータ更新で評価されます。
WITH NOCHECKによって抑制された制約違反 制約が追加されたときに、制約に従わないデータで行を更新すると、将来の更新が失敗する可能性があります。
したがって、WITH NOCHECKを使用します 後で問題が発生する可能性があります。
例3–デフォルトオプションを使用して制約を有効にする
デフォルトのオプションを使用した例を次に示します。
ALTER TABLE Occupation CHECK CONSTRAINT chkJobTitle;
この例は、前の例と同等です。チェックするかどうかを指定しなかったため、SQLServerはWITH NOCHECKが必要であると想定します。 。
WITHNOCHECKを使用すると信頼が失われます
WITH NOCHECKを使用して制約を有効にする場合 、注意すべき1つの結果は、SQLServerがその制約を信頼しなくなったことです。信頼できないものとしてフラグを立てます。
はい、あなたはその権利を読みます。実際にはis_not_trustedがあります SQLServerが1に設定するフラグ CHECKを無効にした場合 制約（信頼されていないことを意味します）、およびそれを0に設定する唯一の方法 （信頼できる）WITH CHECKを指定することです 制約を再度有効にするとき。 WITH NOCHECKを使用する カットしないだけです。
これは完全に理にかなっています。結局のところ、あなた すべてのデータをチェックしていない制約を信頼しますか？
WITH CHECKを使用する 、制約が有効になる前に、既存のすべてのデータをチェックするようにします。有効にできる唯一の方法は、既存のすべてのデータが制約に準拠している場合です。既存のすべてのデータをチェックしたら、信頼できるようになります。
詳細については、SQLServerでCHECK制約を有効にするときにWITHNOCHECKについて知っておくべきことを参照してください。実際のis_not_trustedを確認できます。 CHECKを無効にしてから再度有効にするたびに、フラグが前後に切り替わります。 制約。