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

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

cdn.s3techtraining.com
from cdn.s3techtraining.com More from this publisher
17.06.2013 Views

Chapter 10: Views NULL values will need to appear in the view in order for INSERTs to be allowed through the view. The only way to get around this is — you guessed it — with an INSTEAD OF trigger. Limit What’s Inserted into Views — WITH CHECK OPTION The WITH CHECK OPTION is one of those obscure features in SQL Server. The rules are simple — in order to update or insert data using the view, the resulting row must qualify to appear in the view results. Restated, the inserted or updated row must meet any WHERE criterion that’s used in the SELECT statement that underlies your view. Try It Out WITH CHECK OPTION 310 To illustrate the WITH CHECK OPTION, let’s continue working with the AdventureWorks2008 database, and create a view to show only Portland, Oregon area addresses. We have only limited fields to work with in our Address table, so we’re going to have to make use of the PostalCode in order to figure out where the area address is. We’ve been provided enough information to allow us to filter based on PostalCodes that start with 970, 971, and 972 for the Portland side of the border, and 98660 to 98699 for the Vancouver, Washington side, so we apply it in a view: CREATE VIEW PortlandAreaAddresses_vw AS SELECT AddressID, AddressLine1, City, StateProvinceID, PostalCode, ModifiedDate FROM Person.Address WHERE PostalCode LIKE ‘970%’ OR PostalCode LIKE ‘971%’ OR PostalCode LIKE ‘972%’ OR PostalCode LIKE ‘986[6-9]%’ WITH CHECK OPTION; Run a SELECT * against this view, and you return about 792 rows: AddressID AddressLine1 City StProvID PostalCode ModifiedDate ---------- -------------------- ------------ -------- ---------- ------------ 22 636 Vine Hill Way Portland 58 97205 2001-06-24 312 1286 Cincerto Circle Lake Oswego 58 97034 2002-01-23 322 1 Mt. Dell Drive Portland 58 97205 2002-01-24 … … 29792 5186 Oeffler Ln. Beaverton 58 97005 2003-03-20 29822 2613 West I St. Beaverton 58 97005 2003-12-25 29856 1132 Plymouth Dr. Lake Oswego 58 97034 2004-04-07 (792 row(s) affected)

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

Chapter 10: Views<br />

NULL values will need to appear in the view in order for INSERTs to be allowed through the view. The<br />

only way to get around this is — you guessed it — with an INSTEAD OF trigger.<br />

Limit What’s Inserted into Views — WITH CHECK OPTION<br />

The WITH CHECK OPTION is one of those obscure features in <strong>SQL</strong> <strong>Server</strong>. The rules are simple — in order<br />

to update or insert data using the view, the resulting row must qualify to appear in the view results.<br />

Restated, the inserted or updated row must meet any WHERE criterion that’s used in the SELECT statement<br />

that underlies your view.<br />

Try It Out WITH CHECK OPTION<br />

310<br />

To illustrate the WITH CHECK OPTION, let’s continue working with the AdventureWorks<strong>2008</strong> database,<br />

and create a view to show only Portland, Oregon area addresses. We have only limited fields to work<br />

with in our Address table, so we’re going to have to make use of the PostalCode in order to figure out<br />

where the area address is. We’ve been provided enough information to allow us to filter based on<br />

PostalCodes that start with 970, 971, and 972 for the Portland side of the border, and 98660 to 98699 for<br />

the Vancouver, Washington side, so we apply it in a view:<br />

CREATE VIEW PortlandAreaAddresses_vw<br />

AS<br />

SELECT AddressID,<br />

AddressLine1,<br />

City,<br />

StateProvinceID,<br />

PostalCode,<br />

ModifiedDate<br />

FROM Person.Address<br />

WHERE PostalCode LIKE ‘970%’<br />

OR PostalCode LIKE ‘971%’<br />

OR PostalCode LIKE ‘972%’<br />

OR PostalCode LIKE ‘986[6-9]%’<br />

WITH CHECK OPTION;<br />

Run a SELECT * against this view, and you return about 792 rows:<br />

AddressID AddressLine1 City StProvID PostalCode ModifiedDate<br />

---------- -------------------- ------------ -------- ---------- ------------<br />

22 636 Vine Hill Way Portland 58 97205 2001-06-24<br />

312 1286 Cincerto Circle Lake Oswego 58 97034 2002-01-23<br />

322 1 Mt. Dell Drive Portland 58 97205 2002-01-24<br />

…<br />

…<br />

29792 5186 Oeffler Ln. Beaverton 58 97005 2003-03-20<br />

29822 2613 West I St. Beaverton 58 97005 2003-12-25<br />

29856 1132 Plymouth Dr. Lake Oswego 58 97034 2004-04-07<br />

(792 row(s) affected)

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!