When you browse data, a query operates on one or more database objects and produces a result set. Just like a base table, a result set from a query has columns and rows. A view gives a name to a particular query, and holds the definition in the database system tables.
Suppose you frequently need to list the number of employees in each department. You can get this list with the following statement:
SELECT DepartmentID, COUNT(*) FROM Employees GROUP BY DepartmentID;
You can create a view containing the results of this statement using either Sybase Central or Interactive SQL.
There are some restrictions on the SELECT statements you can use as regular views. In particular, you cannot use an ORDER BY clause in the SELECT query. A characteristic of relational tables is that there is no significance to the ordering of the rows or columns, and using an ORDER BY clause would impose an order on the rows of the view. You can use the GROUP BY clause, subqueries, and joins in view definitions.
To develop a view, tune the SELECT query by itself until it provides exactly the results you need in the format you want. Once you have the SELECT statement just right, you can add a phrase in front of the query to create the view:
CREATE VIEW view-name AS query;
UPDATE, INSERT, and DELETE statements are allowed on some regular views, depending on the view's SELECT statement.
You cannot update views containing aggregate functions, such as COUNT(*). Neither can you update views containing a GROUP BY clause in the SELECT statement, or views containing a UNION statement. In all these cases, there is no way to translate the UPDATE into an action on the underlying tables.
In Sybase Central, you can copy views between databases. To do so, select the view in the right pane of Sybase Central and drag it to the Views folder of another connected database. A new view is then created and the original view's definition is copied to it. Note that only the view definition is copied to the new view. Other view properties, such as permissions, are not copied.
The WITH CHECK OPTION clause is useful for controlling what data is changed when inserting into, or updating, a base table through a view. The following example illustrates this.
Execute the following statement to create the SalesEmployees view with a WITH CHECK OPTION clause.
CREATE VIEW SalesEmployees AS SELECT EmployeeID, GivenName, Surname, DepartmentID FROM Employees WHERE DepartmentID = 200 WITH CHECK OPTION;
Select to view the contents of this view, as follows:
SELECT * FROM SalesEmployees;
Next, attempt to update DepartmentID to 400 for Philip Chin:
UPDATE SalesEmployees SET DepartmentID = 400 WHERE EmployeeID = 129;
Since the WITH CHECK OPTION was specified, the database server evaluates whether the update violates anything in the view definition (in this case, the expression in the WHERE clause). The statement fails (DepartmentID must be 200), and the database server returns the error, "WITH CHECK OPTION violated for insert/update on base table 'Employees'."
If you had not specified the WITH CHECK OPTION in the view definition, the update operation would proceed, causing the Employees table to be modified with the new value, and subsequently causing Philip Chin to disappear from the view.
If a view (for example, View2) is created that references the SalesEmployees view, any updates or inserts on View2 are rejected that would cause the WITH CHECK OPTION criteria on SalesEmployees to fail, even if View2 is defined without a WITH CHECK OPTION clause.
|Send feedback about this page via email or DocCommentXchange||Copyright © 2008, iAnywhere Solutions, Inc. - SQL Anywhere 11.0.0|