以下のコードを使用して、すべてのCHECK
を有効にすることができます SQLServerの現在のデータベースの外部キー制約。
CHECK
を有効にした場合 または外部キー制約の場合、制約を有効にする前にテーブル内の既存のデータをチェックするオプションがあります。これを行うと、既存のものが制約に違反しているかどうかを確認できます。このチェックを実行するには、WITH CHECK
を使用します コード内では、それ以外の場合はWITH NOCHECK
を使用します 。
サンプルコード
すべてのCHECK
を有効にする方法は次のとおりです データベース内の外部キー制約。最初の例は既存のデータをチェックしますが、2番目の例はチェックしません。
チェックあり(推奨):
EXEC sp_MSforeachtable "ALTER TABLE ? WITH CHECK CHECK CONSTRAINT ALL"
チェックなし:
EXEC sp_MSforeachtable "ALTER TABLE ? WITH NOCHECK CHECK CONSTRAINT ALL"
引数名を明示的に指定することもできます(@command1
)必要に応じて(どちらの方法でも同じ結果が得られます)。
チェックあり:
EXEC sp_MSforeachtable @command1="ALTER TABLE ? WITH CHECK CHECK CONSTRAINT ALL"
チェックなし:
EXEC sp_MSforeachtable @command1="ALTER TABLE ? WITH CHECK CHECK CONSTRAINT ALL"
これらの例では、(文書化されていない)sp_MSforeachtable
を使用しています。 ストアドプロシージャ。この手順により、データベース内の各テーブルに対してタスクを実行できます。したがって、ここでのタスクには最適です–すべてのCHECK
を有効にする 現在のデータベース内の外部キー制約。
以下は、これを実行して結果を確認する例です。
例1-制約を確認する
まず、現在のCHECK
を簡単に見ていきます。 データベース内の外部キー制約。それらが有効か無効かを確認します。
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;
結果:
+----------------+-----------------+---------------+------------------+ | Table | Constraint | is_disabled | is_not_trusted | |----------------+-----------------+---------------+------------------| | ConstraintTest | chkPrice | 1 | 1 | | ConstraintTest | chkValidEndDate | 1 | 1 | | ConstraintTest | chkTeamSize | 1 | 1 | | Occupation | chkJobTitle | 1 | 1 | +----------------+-----------------+---------------+------------------+
したがって、現在4つのCHECK
があります 2つの異なるテーブルに対するデータベースの制約制約。
is_disabled であるため、すべての制約が無効になっていることがわかります。 1 に設定されています 。
また、 is_not_trusted であるため、これらはすべて信頼されていません。 1 にも設定されています 。
例2–WITHCHECKを使用して制約を有効にする
次に、WITH CHECK
を使用してすべての制約を有効にします 引数:
EXEC sp_MSforeachtable "ALTER TABLE ? WITH CHECK CHECK CONSTRAINT ALL"
この種のことを行うときは、正しいデータベースを使用していることを確認することをお勧めします。したがって、最初に正しいデータベースに切り替えることでコードを変更できます。
USE Test; EXEC sp_MSforeachtable "ALTER TABLE ? WITH CHECK CHECK CONSTRAINT ALL"
この場合、 Test というデータベースに切り替えます。 ストアドプロシージャを実行する前に。
例3–結果を確認する
上記のコードを実行したら、最初の例と同じクエリを実行して結果を確認します。
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;
結果:
+----------------+-----------------+---------------+------------------+ | Table | Constraint | is_disabled | is_not_trusted | |----------------+-----------------+---------------+------------------| | ConstraintTest | chkPrice | 0 | 0 | | ConstraintTest | chkValidEndDate | 0 | 0 | | ConstraintTest | chkTeamSize | 0 | 0 | | Occupation | chkJobTitle | 0 | 0 | +----------------+-----------------+---------------+------------------+
これで、データベース内のすべての制約が有効になりました( is_disabled が原因) 列が 0 に設定されている すべての制約に対して)。
is_not_trusted もわかります 列も 0 に設定されます 。これは、制約が信頼されていることを意味します。有効にする前に既存のすべてのデータをチェックできるため、信頼できます。
WITH NOCHECK
を使用した場合 、制約は信頼されないままになります(つまり、
is_not_trusted
フラグは
1
に設定されます )。これは、データベースに1つ(または複数)の制約に違反するデータが含まれている可能性があるためです(制約が無効になっているときに無効なデータがデータベースに入力された可能性があります)。
まれに、データベースに無効なデータを保持する必要がある場合があります。このような場合、既存のデータは初期チェックに合格せず、WITH NOCHECK
を使用しない限り制約を有効にできないため、制約は信頼されないままにする必要があります。 。
制約を無効にしてから再度有効にするときに信頼できるものと信頼できないものを切り替える詳細な例については、SQLServerでCHECK制約を有効にする場合のWITHNOCHECKについて知っておくべきことを参照してください。
制約を個別に有効にする
制約を1つずつ有効にするだけの場合は、SQLServerでCHECK制約を有効にする方法およびSQLServerで外部キーを有効にする方法を参照してください。