SQL/MX 3.2.1 Management Manual (H06.26+, J06.15+)

For more information, see the SQL/MX Reference Manual.
Recovering SQL/MX Tables Dropped Accidentally
If you drop a table accidentally, you can recover the table using the DDL file generated automatically
by NonStop SQL/MX. For more information, see “Using TMF to Recover Dropped SQL/MX Objects”
(page 56) and the “Recovering Tables” (page 240).
Dropping SQL/MX Table Data Only
To drop data from a table while leaving the table intact, use the PURGEDATA utility.
PURGEDATA drops all data from both tables and their related indexes, or from specific partitions
of tables that have no indexes.
Guidelines for Dropping Table Data Only
• To use PURGEDATA, you must have ALL privileges on the table you specify (DELETE, INSERT,
SELECT, and UPDATE) or you must own the table, or you must be the super ID.
• If PURGEDATA fails in response to a process, CPU, or system error, you must use the RECOVER
utility to recover the operation. If the PURGEDATA operation cannot be canceled, RECOVER
returns an error.
For more information, see “Using PURGEDATA to Delete Data From Tables” (page 210) and the
SQL/MX Reference Manual.
Steps for Dropping a Table’s Data Only
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 table containing the data you want to drop.
3. Use the PURGEDATA utility to drop the data.
4. Make new TMF online dumps of all affected partitions.
For more information, see the SQL/MX Reference Manual.
Dropping Triggers
To drop a trigger from an SQL/MX table, use the DROP TRIGGER statement.
To drop a trigger, you must be the owner of the trigger, or own its schema or be the super ID.
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 want 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 more information about explicit and automatic recompilation, see the SQL/MX Programming
Manual for C and COBOL. For more information about using DISPLAY USE OF, see “Checking
Module Dependencies with DISPLAY USE OF” (page 226) and the SQL/MX Reference Manual.
176 Adding, Altering, and Dropping SQL/MX Database Objects