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

Now try to update one of the rows using the view — set the PostalCode to anything other than a value
starting with 97 or 98:
UPDATE PortlandAreaAddresses_vw
SET PostalCode = ‘33333’ -- it was 97205
WHERE AddressID = 22;
SQL Server promptly tells you that you are a scoundrel and that you should be burned at the stake for
your actions — well, not really, but it does make its point:
Msg 550, Level 16, State 1, Line 1
The attempted insert or update failed because the target view either specifies WITH
CHECK OPTION or spans a view that specifies WITH CHECK OPTION and one or more rows
resulting from the operation did not qualify under the CHECK OPTION constraint.
The statement has been terminated.
How It Works
Our WHERE clause filters things in the view to show only postal codes that start with 970, 971, 972, or
9866-9869, and the WITH CHECK OPTION says any INSERT or UPDATE statements must meet that WHERE
clause criteria (which a (33333) postal code doesn’t).
Since our update wouldn’t meet the WHERE clause criteria, it is thrown out; however, if we were to
update the row right in the base table:
UPDATE Person.Address
SET PostalCode = ‘33333’ -- it was 97205
WHERE AddressID = 22;
SQL Server is a lot friendlier:
(1 row(s) affected)
Chapter 10: Views
The restriction applies only to the view — not to the underlying table. This can actually be quite handy
in a rare circumstance or two. Imagine a situation where you want to allow some users to insert or update
data in a table, but only when the updated or inserted data meets certain criteria. We could easily deal
with this restriction by adding a CHECK constraint to our underlying table — but this might not always
be an ideal solution.
Imagine now that we’ve added a second requirement — we still want other users to be able to INSERT
data into the table without meeting these criteria. Uh oh, the CHECK constraint will not discriminate
between users. By using a view together with a WITH CHECK OPTION, we can point the restricted users
to the view, and let the unrestricted users make use of the base table or a view that has no such restriction.
Note that this works on an INSERT, too. Run an INSERT that violates the WHERE clause and you’ll see
your old friend, the “terminator” error, exactly as we did with the UPDATE.
311