I needed to alter the conditions of existing constraint – so I dropped it and recreated with the new conditions.
This failed, because there were 800k+ rows, that didn't meet the condition. That strikes me as odd, because
SELECT * FROM sys.[check_constraints] cc
showed is_not_trusted
as 0
Anyway, I recreated the constraint again, this time with hint WITH NOCHECK
This time it passed and I expected is_not_trusted
to be 1
, but it is still trusted.
Can someone explain it to me?
My code:
ALTER TABLE dbo.MyTable
DROP CONSTRAINT CK_MyTable;
GO
ALTER TABLE dbo.MyTable WITH NOCHECK
ADD CONSTRAINT CK_MyTable
CHECK
(
-- 7 conditions, mainly checking null and not null
)
Best Answer
This might not be an accepted answer and I am ok with that but I cannot put the whole thing in a comment.
I tested your scenario with SQL Server 2016, SP2 and SQL Server 2017 CU9. In both cases I get expected result for
is_not_trusted
column value. Meaning 1 while usingWITH NOCHECK
and 0 while using `WITH CHECK'Here is my test code. Some of the code I used is from Search Engine Q&A #9: How to update constraints? written by Paul Randal.
Result I get is following: