Beginning Microsoft SQL Server 2008 ... - S3 Tech Training
Beginning Microsoft SQL Server 2008 ... - S3 Tech Training Beginning Microsoft SQL Server 2008 ... - S3 Tech Training
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
- Page 297 and 298: Chapter 8: Being Normal: Normalizat
- Page 299 and 300: 9 SQL Ser ver Storage and Index Str
- Page 301 and 302: Page Splits When a page becomes ful
- Page 303 and 304: The point here is that what happens
- Page 305 and 306: Page Splits — A First Look All of
- Page 307 and 308: You may hear lots of bad things abo
- Page 309 and 310: Navigating the Tree Figure 9-4 As I
- Page 311 and 312: there was no link between the data.
- Page 313 and 314: Root Non-Leaf Level Leaf Level Figu
- Page 315 and 316: The CREATE INDEX Statement The CREA
- Page 317 and 318: FILLFACTOR When SQL Server first cr
- Page 319 and 320: works only if tempdb is on a separa
- Page 321 and 322: Secondary XML Indexes Chapter 9: SQ
- Page 323 and 324: occur, and that one or more non-lea
- Page 325 and 326: isn’t room on the page, SQL Serve
- Page 327 and 328: more administrator oriented and usu
- Page 329 and 330: The Database Engine Tuning Advisor
- Page 331 and 332: The output is far more self-describ
- Page 333 and 334: We use a FILLFACTOR when we need to
- Page 335: Chapter 9: SQL Server Storage and I
- Page 338 and 339: Chapter 10: Views The preceding syn
- Page 340 and 341: Chapter 10: Views 302 columns to a
- Page 342 and 343: Chapter 10: Views Try It Out Using
- Page 344 and 345: Chapter 10: Views 306 soh.SalesOrde
- Page 346 and 347: Chapter 10: Views AW00000676 43659
- Page 350 and 351: Chapter 10: Views Editing V iews wi
- Page 352 and 353: Chapter 10: Views 314 There are fou
- Page 354 and 355: Chapter 10: Views Editing Views in
- Page 356 and 357: Chapter 10: Views 318 In addition,
- Page 358 and 359: Chapter 10: Views 320 from the firs
- Page 360 and 361: Chapter 10: Views You can get the y
- Page 363 and 364: 11 Writing Scripts and Batches Whet
- Page 365 and 366: Next we have a DECLARE statement to
- Page 367 and 368: I’m not going to pick any bones a
- Page 369 and 370: Using @@IDENTITY @@IDENTITY is one
- Page 371 and 372: How It Works What we’re doing in
- Page 373 and 374: DECLARE @RowCount int; --Notice the
- Page 375 and 376: When the editing tool encounters a
- Page 377 and 378: When you think about it, this seems
- Page 379 and 380: So, let’s try a quick query direc
- Page 381 and 382: We now have our text file source fo
- Page 383 and 384: Let’s build an example in the Adv
- Page 385 and 386: DECLARE @InVar varchar(50); DECLARE
- Page 387 and 388: -- This won’t work DECLARE @Numbe
- Page 389 and 390: -- Now we’re run our conditional
- Page 391 and 392: Out of the condition from inner con
- Page 393 and 394: A Simple CASE A simple CASE takes a
- Page 395 and 396: 3 8 More Than One Apart 2 2 Ends Wi
- Page 397 and 398: Now, I don’t know about you, but
Now try to update one of the rows using the view — set the PostalCode to anything other than a value<br />
starting with 97 or 98:<br />
UPDATE PortlandAreaAddresses_vw<br />
SET PostalCode = ‘33333’ -- it was 97205<br />
WHERE AddressID = 22;<br />
<strong>SQL</strong> <strong>Server</strong> promptly tells you that you are a scoundrel and that you should be burned at the stake for<br />
your actions — well, not really, but it does make its point:<br />
Msg 550, Level 16, State 1, Line 1<br />
The attempted insert or update failed because the target view either specifies WITH<br />
CHECK OPTION or spans a view that specifies WITH CHECK OPTION and one or more rows<br />
resulting from the operation did not qualify under the CHECK OPTION constraint.<br />
The statement has been terminated.<br />
How It Works<br />
Our WHERE clause filters things in the view to show only postal codes that start with 970, 971, 972, or<br />
9866-9869, and the WITH CHECK OPTION says any INSERT or UPDATE statements must meet that WHERE<br />
clause criteria (which a (33333) postal code doesn’t).<br />
Since our update wouldn’t meet the WHERE clause criteria, it is thrown out; however, if we were to<br />
update the row right in the base table:<br />
UPDATE Person.Address<br />
SET PostalCode = ‘33333’ -- it was 97205<br />
WHERE AddressID = 22;<br />
<strong>SQL</strong> <strong>Server</strong> is a lot friendlier:<br />
(1 row(s) affected)<br />
Chapter 10: Views<br />
The restriction applies only to the view — not to the underlying table. This can actually be quite handy<br />
in a rare circumstance or two. Imagine a situation where you want to allow some users to insert or update<br />
data in a table, but only when the updated or inserted data meets certain criteria. We could easily deal<br />
with this restriction by adding a CHECK constraint to our underlying table — but this might not always<br />
be an ideal solution.<br />
Imagine now that we’ve added a second requirement — we still want other users to be able to INSERT<br />
data into the table without meeting these criteria. Uh oh, the CHECK constraint will not discriminate<br />
between users. By using a view together with a WITH CHECK OPTION, we can point the restricted users<br />
to the view, and let the unrestricted users make use of the base table or a view that has no such restriction.<br />
Note that this works on an INSERT, too. Run an INSERT that violates the WHERE clause and you’ll see<br />
your old friend, the “terminator” error, exactly as we did with the UPDATE.<br />
311