An untrusted foreign key has not validated all existing rows. The question arose during a customer health check.

SELECT s.name AS SchemaName,t.name AS TableName,f.name AS KeyName,
f.is_not_trusted,f.is_disabled,f.is_not_for_replication
FROM sys.foreign_keys f JOIN sys.tables t ON t.object_id=f.parent_object_id
JOIN sys.schemas s ON s.schema_id=t.schema_id
WHERE f.is_not_trusted=1 ORDER BY s.name,t.name,f.name;
-- After fixing violations and reviewing locking/validation cost:
-- ALTER TABLE dbo.YourTable WITH CHECK CHECK CONSTRAINT YourForeignKey;My original filter selected enabled, untrusted keys without NOT FOR REPLICATION. This inventory exposes all three flags. Deliberately narrow it when that older scope is required. Excluded cases are not proof of absent problems.
An enabled untrusted key can enforce new changes despite unvalidated existing data. NOCHECK has statement-specific effects on validation and enforcement. Untrusted and disabled describe different states.
Trusted relationships can assist optimization. Check violations and ownership before WITH CHECK CHECK CONSTRAINT. Validation can fail, lock data and consume resources. Test and schedule it instead of enabling every discovered key.
A missing relationship deserves a business-rule and data-integrity review. Catalog presence alone does not establish correctness. Assess the actual rule and data.
Reference: Foreign-key enforcement and trust.
Related reading
An untrusted constraint is not necessarily disabled, it is a relationship whose existing-data validation state differs from enforcement.
Published by Pinal Dave on SQLAuthority. More of my work at pinaldave.com.
Discover more from SQL Authority with Pinal Dave
Subscribe to get the latest posts sent to your email.





4 Comments. Leave new
You will want to fix liine 2 ;P
Totally.
I just recently experienced something very odd. I know if you alter a foreign key to be ‘NOCHECK’, and then alter it back with just “CHECK”, the foreign key will apply to all new data, but won’t check existing data. This is when the FK is “untrusted”. Doing a “WITH CHECK CHECK” will check all existing data (may be slow), and will make the FK “trusted”.
But what I experienced is a table with a foreign key that was TRUSTED, yet trying to alter “WITH CHECK CHECK” returned an error… meaning there were rows that did not have associated data in the other table. How is this possible? It seems like I can’t trust the “is trusted” property of a foreign key.
Very strange behavior indeed. I have no answer as well.