In other words, we can no longer assume that the constraint has checked all the data. This indicates that the CHECK constraint has not been verified by the system for all rows.
You might notice that the is_not_trusted column is also set to 1. We can see that this is the only one that’s disabled (because its is_disabled column is set to 1).
In this case I selected all CHECK constraints from the current database. | chkTeamSize | 0 | 0 | (>=(5) AND 'Digital Nomad') | | name | is_disabled | is_not_trusted | definition | We can query the sys.check_constraints system view to verify that our constraint has been disabled: SELECT This code disables a constraint called chkJobTitle. To disable a CHECK constraint, use the NOCHECK argument within an ALTER TABLE statement.
Here’s how to do that using Transact-SQL. If you find yourself in this situation, you can always disable the constraint. Either way, you won’t be able to enter anything outside the rules of the constraint. If you attempt to enter invalid data, the operation will fail with an error.īut what if you find yourself in the situation where you really must insert data that will violate the CHECK constraint? Perhaps the constraint no longer applies, or maybe you have an exception where one row is allowed to bypass the constraint. When you attempt to enter data into a table that has a fully enabled CHECK constraint, you will only be successful if the data doesn’t violate that constraint.