SQL/MX 2.x Installation and Management Guide (H06.10+, J06.03+)

Adding, Altering, and Dropping SQL/MX Database
Objects
HP NonStop SQL/MX Installation and Management Guide—544536-007
9-37
Dropping Views
To drop a trigger, you must own its schema or be the super ID. If you specify the
CASCADE option for the DROP TRIGGER statement, you can also drop any objects
used by the trigger (for example, tables, views or columns).
For more information, see the SQL/MX Reference Manual.
Steps for Dropping a Trigger
1. Start an MXCI session. Enter a LOG command to initiate a log file for statements
and commands entered in this session. Keep the log for your records.
2. Determine the name of the trigger you wish to drop.
3. Use the DISPLAY USE OF command to identify which user modules are
associated with this object. See the similarity check criteria in the SQL/MX
Programming Manual for C and COBOL to determine if your changes are likely to
cause similarly check to fail and force automatic recompilation. If they will, you
should SQL compile these modules after making the changes to avoid expensive
automatic recompilations at run time. SQL applications that are running while you
make these changes will still undergo automatic recompilation.
For information about explicit and automatic recompilation, see the SQL/MX
Programming Manual for C and COBOL. For information about using DISPLAY
USE OF, see Checking Module Dependencies with DISPLAY USE OF on
page 11-19 and the SQL/MX Reference Manual.
4. Enter the DROP TRIGGER statement.
5. Revise the application source code as needed to reflect your changes to the
database. Process and compile the updated source file. For more information, see
the SQL/MX Programming Manual for C and COBOL.
For more information and examples of dropping triggers, see the SQL/MX Reference
Manual.
Dropping Views
To drop a view of SQL/MX data, use the DROP VIEW statement. To drop a view, you
must own its schema or be the super ID.
The RESTRICT option, by default, will not allow a view to be dropped if it is referenced
in the query expression of any other view or in the search condition of another object's
constraint. The CASCADE option, if specified, will drop both the view and any such
dependent objects
Dropping a view with dependencies is essentially the same as dropping the view and
each of its dependent objects separately. Although SQL can drop all dependent objects
automatically, it does not drop any dependent programs. Dropping a view invalidates
all programs that use the view, however, and HP recommends that you update and
recompile these programs explicitly after dropping the view to avoid errors and
expensive, automatic recompilations.