Use this statement to replace a view definition with a modified version.
ALTER VIEW [ owner.]view-name [ ( column-name, ... ) ] AS select-statement [ WITH CHECK OPTION ]
ALTER VIEW [ owner.]view-name { SET HIDDEN | RECOMPILE | DISABLE | ENABLE }
AS clause The purpose and syntax of this clause is identical to that of the CREATE VIEW statement. See CREATE VIEW statement.
WITH CHECK OPTION clause The purpose and syntax of this clause is identical to that of the CREATE VIEW statement. See CREATE VIEW statement.
SET HIDDEN clause Use the SET HIDDEN clause to obfuscate the definition of the view and cause the view to become hidden from view, for example in Sybase Central. Explicit references to the view will still work, however.
The SET HIDDEN operation is irreversible.
RECOMPILE clause Use the RECOMPILE clause to re-create the column definitions for the view. This clause is identical in functionality to the ENABLE clause, except that you may decide to use it on a view that is not disabled. When a view is recompiled, the database server restores the column permissions based on the column names specified in the new view definition. The existing permissions are lost when a column no longer exists after the recompilation.
DISABLE clause Use the DISABLE clause to disable the view from use by the database server.
ENABLE clause Use the ENABLE clause to enable a disabled view. Enabling the view causes the database server to re-create the column definitions for the view. Before you enable a view, you must enable any views upon which it depends.
If you alter a view owned by another user, you must qualify the name by including the owner (for example, GROUPO.ViewSalesOrders). If you don't qualify the name, the database server looks for a view with that name owned by you and alters it. If there isn't one, it returns an error.
When you alter a view, existing permissions on the view are maintained, and do not have to be reassigned. Instead of using the ALTER VIEW statement, you could also drop the view and recreate it using the DROP VIEW and CREATE VIEW, respectively. However, if you do so, permissions on the view need to be reassigned.
After completing the view alteration using Syntax 1, the database server recompiles the view. Depending on the type of change you made, if there are dependent views, the database server will attempt to recompile them as well. If you have made a change that impacts a dependent view, you may need to alter the definition for the dependent view as well. For more information about view alterations and how they impact view dependencies, see View dependencies.
If the SELECT statement defining the view contained an asterisk (*), the number of the columns in the view may change if columns have been added or deleted from the underlying tables. The names and data types of the view columns may also change.
Syntax 1 This syntax is used to alter the structure of the view. Unlike altering tables where your change may be limited to individual columns, altering the structure of a view requires you to replace the entire view definition with a new definition, much as you would for creating the view. For a description of the parameters used to define the structure of a view, see CREATE VIEW statement.
Syntax 2 This syntax is used to change attributes for the view, such as whether the view definition is hidden.
When you use SET HIDDEN, the view can be unloaded and reloaded into other databases. If SET HIDDEN is used, debugging using the debugger will not show the view definition, nor will it be available through procedure profiling. If you need to change the definition of a hidden view, you must drop the view and create it again using the CREATE VIEW statement.
When you use the DISABLE clause, the view is no longer available for use by the database server for answering queries. Disabling a view is similar to dropping it, except that the view definition remains in the database. Disabling a view also disables any dependent views. Therefore, the DISABLE clause requires exclusive access not only to the view being disabled, but also any dependent views, since they are disabled too.
Must be owner of the view or have DBA authority.
Automatic commit.
All procedures and triggers are unloaded from memory, so that any procedure or trigger that references the view reflects the new view definition. The unloading and loading of procedures and triggers can have a performance impact if you are regularly altering views.
SQL/2003 Vendor extension.
| Discuss this page in DocCommentXchange. Send feedback about this page using email. |
Copyright © 2009, iAnywhere Solutions, Inc. - SQL Anywhere 11.0.1 |