Beginning SQL
Beginning SQL Beginning SQL
However, someone writes a query that mistakenly inserts a member in another state: INSERT INTO MemberBirthdaysGoldenState (MemberId, LastName, FirstName, DateOfBirth, Street, City, State, ZipCode, Email, DateOfJoining) VALUES (7, ‘Smith’, ‘Marty’, ‘3/23/1974’, ‘123 North Rd’, ‘Idlewild’, ‘New State’, 65421, ‘msmith@SmithSonJonSon.com’, ‘3/01/2004’) This is a perfectly valid SQL statement, however, and the query inserts a new record into the MemberDetails table in a state that is not visible in the view, and which does not belong to the user doing the update. This user cannot see the new record and thinks that the DBMS ignored his request, and some other user now finds a record in his state for a member he didn’t add. In order to prevent this kind of problem, you might want to disallow these updates from occurring through the view. The DBMS can do this for you using the CHECK OPTION keyword in the CREATE VIEW statement, as shown below in the new version of the view: CREATE VIEW MemberBirthdaysGoldenStateCheckOption AS SELECT MemberId, FirstName, LastName, DateOfBirth, Street, City, State, ZipCode, Email, DateOfJoining FROM dbo.MemberDetails WHERE (State = ‘Golden State’) WITH CHECK OPTION When you specify the CHECK OPTION keyword in a CREATE VIEW statement, the DBMS stores the CHECK OPTION with the view. Whenever a user performs an UPDATE, INSERT, or DELETE on the view, the DBMS checks each operation to ensure that it meets the WHERE criteria. Any operations failing to meet the WHERE criteria are not performed. For example, an attempt to execute the following statement would fail: INSERT INTO MemberBirthdaysGoldenStateCheckOption (MemberId, LastName, FirstName, DateOfBirth, Street, City, State, ZipCode, Email, DateOfJoining) VALUES (7, ‘Smith’, ‘Marty’, ‘3/23/1974’, ‘123 North Rd’, ‘Idlewild’, ‘New State’, 65421, ‘msmith@SmithSonJonSon.com’, ‘3/01/2004’) You would see results similar to Figure 10-12. Figure 10-12 Views As you might imagine, CHECK OPTION can add significant overhead to an action query. Each record being updated has to be checked for conformance with the view. Additionally, you can build views based on other views, and each may have a CHECK OPTION. Each level must be checked to ensure that the requested operation passes its check. 297
- Page 584: Chapter 9 272 FirstName LastName Mo
- Page 588: Chapter 9 274 DVDPrice column is in
- Page 592: Chapter 9 SalesPersonId FirstName L
- Page 596: Chapter 9 278 SalesPersonId MemberI
- Page 600: Chapter 9 280 SalesPersonId MemberI
- Page 604: Chapter 9 282 MemberDetails.FirstNa
- Page 608: Chapter 9 284 The query would work
- Page 612: Chapter 9 Exercises 286 Assume that
- Page 616: Chapter 10 Now that you know what v
- Page 620: Chapter 10 Types of Views Given tha
- Page 624: Chapter 10 Perhaps you need to view
- Page 628: Chapter 10 Figure 10-7 Summary view
- Page 632: Chapter 10 296 This statement gives
- Page 638: Summary As you learned, views are l
- Page 644: Chapter 11 The information that fol
- Page 648: Chapter 11 This SQL adds formats (d
- Page 652: Chapter 11 TRANSACTION statement is
- Page 656: Chapter 11 Additionally, if a DBMS
- Page 660: Chapter 11 ROLLBACK TRANSACTION 310
- Page 664: Chapter 11 Transaction Logs 312 How
- Page 668: Chapter 11 Database There are perfe
- Page 672: Chapter 11 In order to find and fix
- Page 676: Chapter 11 When discussing locking,
- Page 680: Chapter 11 Usually, the default iso
However, someone writes a query that mistakenly inserts a member in another state:<br />
INSERT INTO MemberBirthdaysGoldenState<br />
(MemberId, LastName, FirstName, DateOfBirth, Street, City,<br />
State, ZipCode, Email, DateOfJoining)<br />
VALUES (7, ‘Smith’, ‘Marty’, ‘3/23/1974’, ‘123 North Rd’, ‘Idlewild’, ‘New<br />
State’, 65421, ‘msmith@SmithSonJonSon.com’, ‘3/01/2004’)<br />
This is a perfectly valid <strong>SQL</strong> statement, however, and the query inserts a new record into the<br />
MemberDetails table in a state that is not visible in the view, and which does not belong to the user<br />
doing the update. This user cannot see the new record and thinks that the DBMS ignored his request,<br />
and some other user now finds a record in his state for a member he didn’t add.<br />
In order to prevent this kind of problem, you might want to disallow these updates from occurring<br />
through the view. The DBMS can do this for you using the CHECK OPTION keyword in the CREATE VIEW<br />
statement, as shown below in the new version of the view:<br />
CREATE VIEW MemberBirthdaysGoldenStateCheckOption AS<br />
SELECT MemberId, FirstName, LastName, DateOfBirth, Street, City, State,<br />
ZipCode, Email, DateOfJoining<br />
FROM dbo.MemberDetails<br />
WHERE (State = ‘Golden State’)<br />
WITH CHECK OPTION<br />
When you specify the CHECK OPTION keyword in a CREATE VIEW statement, the DBMS stores the<br />
CHECK OPTION with the view. Whenever a user performs an UPDATE, INSERT, or DELETE on the view,<br />
the DBMS checks each operation to ensure that it meets the WHERE criteria. Any operations failing to<br />
meet the WHERE criteria are not performed. For example, an attempt to execute the following statement<br />
would fail:<br />
INSERT INTO MemberBirthdaysGoldenStateCheckOption<br />
(MemberId, LastName, FirstName, DateOfBirth, Street, City, State, ZipCode,<br />
Email, DateOfJoining)<br />
VALUES<br />
(7, ‘Smith’, ‘Marty’, ‘3/23/1974’, ‘123 North Rd’, ‘Idlewild’, ‘New State’,<br />
65421,<br />
‘msmith@SmithSonJonSon.com’, ‘3/01/2004’)<br />
You would see results similar to Figure 10-12.<br />
Figure 10-12<br />
Views<br />
As you might imagine, CHECK OPTION can add significant overhead to an action query. Each record<br />
being updated has to be checked for conformance with the view. Additionally, you can build views<br />
based on other views, and each may have a CHECK OPTION. Each level must be checked to ensure that<br />
the requested operation passes its check.<br />
297