Следното ще върне името на външните ключове в текущата база данни, които са деактивирани, т.е. С NOCHECK
За SQL Server 2005/2008:
select * from sys.foreign_keys where is_disabled=1
Имаше известна дискусия в отговора относно разликата между забранени и ненадеждни. Това, което е по-долу, обяснява разликата. Ето някакъв код за изясняване на разликата между is_disabled и ненадеждни.
-- drop table t1
-- drop table t2
create table t1(i int not null, fk int not null)
create table t2(i int not null)
-- create primary key on t2
alter table t2
add constraint pk_1 primary key (i)
-- create foriegn key on t1
alter table t1
add constraint fk_1 foreign key (fk)
references t2 (i)
--insert some records
insert t2 values(100)
insert t2 values(200)
insert t2 values(300)
insert t2 values(400)
insert t2 values(500)
insert t1 values(1,100)
insert t1 values(2,100)
insert t1 values(3,500)
insert t1 values(4,500)
----------------------------
-- 1. enabled and trusted
select name,is_disabled,is_not_trusted from sys.foreign_keys
GO
-- 2. disable the constraint
alter table t1 NOCHECK CONSTRAINT fk_1
select name,is_disabled,is_not_trusted from sys.foreign_keys
GO
-- 3. re-enable constraint, data isnt checked, so not trusted.
-- this means the optimizer will still have to check the column
alter table t1 CHECK CONSTRAINT fk_1
select name,is_disabled,is_not_trusted from sys.foreign_keys
GO
--4. drop the foreign key constraint & re-add
-- it making sure its checked
-- constraint is then enabled and trusted
alter table t1 DROP CONSTRAINT fk_1
alter table t1 WITH CHECK
add constraint fk_1 foreign key (fk)
references t2 (i)
select name,is_disabled,is_not_trusted from sys.foreign_keys
GO
--5. drop the foreign key constraint & add but dont check
-- constraint is then enabled, but not trusted
alter table t1 DROP CONSTRAINT fk_1
alter table t1 WITH NOCHECK
add constraint fk_1 foreign key (fk)
references t2 (i)
select name,is_disabled,is_not_trusted from sys.foreign_keys
GO
is_disabled
означава, че ограничението е деактивирано
isnottrusted
означава, че SQL Server не вярва, че колоната е проверена спрямо таблицата с външни ключове.
Следователно не може да се приеме, че повторното активиране на ограничението за външен ключ ще бъде оптимизирано. За да сте сигурни, че оптимизаторът вярва на колоната, най-добре е да премахнете ограничението за външен ключ и да го създадете отново с WITH CHECK
опция (4.)