Beginning Microsoft SQL Server 2008 ... - S3 Tech Training

Chapter 6: Constraints
Try running a SELECT on the Customers table at this point. You’ll see data that both does and does not
adhere to our CHECK constraint criterion:
SELECT CustomerNo, CustomerName, Phone FROM Customers;
CustomerNo CustomerName Phone
------------ --------------------- --------------
1 Billy Bob’s Shoes (360) 555-1234
2 Customer1 553-1212
3 MyCust 555-1212
5 MyCust (800) 555-1212
(2 row(s) affected)
The old data is retained for back reference, but any new data is restricted to meeting the new criteria.
Temporarily Disabling an Existing Constraint
178
All right, so you understand why we need to be able to add new constraints that do not check old data,
but why would we want to temporarily disable an existing constraint? Why would we want to let data
that we know is bad be added to the database? Actually, the most common reason is basically the same
reason for which we make use of the WITH NOCHECK option — old data.
Old data doesn’t just come in the form of data that has already been added to your database. It may also
be data that you are importing from a legacy database or some other system. Whatever the reason, the
same issue still holds: You have some existing data that doesn’t match up with the rules, and you need
to get it into the table.
Certainly one way to do this would be to drop the constraint, add the desired data, and then add the
constraint back using a WITH NOCHECK. But what a pain! Fortunately, we don’t need to do that. Instead,
we can run an ALTER statement with an option called NOCHECK that turns off the constraint in question.
Here’s the code that disables the CHECK constraint that we just added in the previous section:
ALTER TABLE Customers
NOCHECK
CONSTRAINT CN_CustomerPhoneNo;
Now we can run that INSERT statement again — the one we proved wouldn’t work if the constraint
were active:
INSERT INTO Customers
(CustomerName,
Address1,
Address2,
City,
State,
Zip,
Contact,
Phone,