проверьте, включены ли внешние ключи в таблице [duplicate]

Я знаю, что это старый вопрос с некоторыми старыми ответами, в которых есть хорошая информация. Тем не менее, я просто хотел поделиться сценарием, который я использовал для решения этой проблемной области, в нескольких разных базах данных для нас:

-- Foreign Keys
SELECT 'ALTER TABLE ' + o.name + ' WITH CHECK CHECK CONSTRAINT ' + i.name + ';' AS AlterStatement
from sys.foreign_keys i
INNER JOIN sys.objects o ON i.parent_object_id = o.object_id
INNER JOIN sys.schemas s ON o.schema_id = s.schema_id
WHERE i.is_not_trusted = 1 AND i.is_not_for_replication = 0;
GO

-- Constraints
SELECT 'ALTER TABLE ' + o.name + ' WITH CHECK CHECK CONSTRAINT ' + i.name + ';' AS AlterStatement
from sys.check_constraints i
INNER JOIN sys.objects o ON i.parent_object_id = o.object_id
INNER JOIN sys.schemas s ON o.schema_id = s.schema_id
WHERE i.is_not_trusted = 1 AND i.is_not_for_replication = 0 AND i.is_disabled = 0;
GO

Это создаст коллекцию операторов ALTER, чтобы исправить это " NOCHECK "с внешними ключами и ограничениями. Это основано на некоторых запросах, предоставленных Brent Ozar , но измененных мной для моих целей и простоты использования. Это можно легко настроить с помощью UNION, чтобы сделать его одним запросом.

FYI, я использовал это исключительно в среде Azure SQL Database. Я не уверен, существуют ли ограничения для старых версий SQL Server, но он отлично работает в Azure.

С NOCHECK следует применять только к FK временно, или они становятся бесполезными для оптимизатора, как указывает ваша связанная статья. Из BOL:

Оптимизатор запросов не рассматривает ограничения, которые определены WITH NOCHECK. Такие ограничения игнорируются до тех пор, пока они не будут повторно активированы с помощью таблицы ALTER TABLE CHECK CONSTRAINT ALL.

Это будет идентифицировать все ваши внешние ключи: (работа с битом WITH NOCHECK ...)

SELECT C.TABLE_CATALOG [PKTABLE_QUALIFIER], 
       C.TABLE_SCHEMA [PKTABLE_OWNER], 
       C.TABLE_NAME [PKTABLE_NAME], 
       KCU.COLUMN_NAME [PKCOLUMN_NAME], 
       C2.TABLE_CATALOG [FKTABLE_QUALIFIER], 
       C2.TABLE_SCHEMA [FKTABLE_OWNER], 
       C2.TABLE_NAME [FKTABLE_NAME], 
       KCU2.COLUMN_NAME [FKCOLUMN_NAME], 
       RC.UPDATE_RULE, 
       RC.DELETE_RULE, 
       C.CONSTRAINT_NAME [FK_NAME], 
       C2.CONSTRAINT_NAME [PK_NAME], 
       CAST(7 AS SMALLINT) [DEFERRABILITY] 
FROM   INFORMATION_SCHEMA.TABLE_CONSTRAINTS C 
       INNER JOIN INFORMATION_SCHEMA.KEY_COLUMN_USAGE KCU 
         ON C.CONSTRAINT_SCHEMA = KCU.CONSTRAINT_SCHEMA 
            AND C.CONSTRAINT_NAME = KCU.CONSTRAINT_NAME 
       INNER JOIN INFORMATION_SCHEMA.REFERENTIAL_CONSTRAINTS RC 
         ON C.CONSTRAINT_SCHEMA = RC.CONSTRAINT_SCHEMA 
            AND C.CONSTRAINT_NAME = RC.CONSTRAINT_NAME 
       INNER JOIN INFORMATION_SCHEMA.TABLE_CONSTRAINTS C2 
         ON RC.UNIQUE_CONSTRAINT_SCHEMA = C2.CONSTRAINT_SCHEMA 
            AND RC.UNIQUE_CONSTRAINT_NAME = C2.CONSTRAINT_NAME 
       INNER JOIN INFORMATION_SCHEMA.KEY_COLUMN_USAGE KCU2 
         ON C2.CONSTRAINT_SCHEMA = KCU2.CONSTRAINT_SCHEMA 
            AND C2.CONSTRAINT_NAME = KCU2.CONSTRAINT_NAME 
            AND KCU.ORDINAL_POSITION = KCU2.ORDINAL_POSITION 
WHERE  C.CONSTRAINT_TYPE = 'FOREIGN KEY'

Ref .

Как и в случае с SQL Server 2000 и 2005, вы можете проверить, не нарушает ли какое-либо ограничение ограничение, используя:

DBCC CHECKCONSTRAINTS (table_name)

Следующий скрипт будет генерировать инструкции alter, которые будут проверять существующие данные и предотвращать любые новые нарушения для внешних ключей, которые в настоящее время не доверяют («с nocheck»).

Выполнить его в SQL Server Management Studio, чтобы сгенерировать скрипты, а затем скопировать их в окно запроса для их выполнения.

select
    'alter table ' + quotename(s.name) + '.' + quotename(t.name) + ' with check check constraint ' + fk.name +';'
from 
    sys.foreign_keys fk
inner join
    sys.tables t
on
    fk.parent_object_id = t.object_id
inner join
    sys.schemas s
on
    t.schema_id = s.schema_id
where 
    fk.is_not_trusted = 1