Oninit
Talk to an expert →

Informix Error -372

-372 Cannot alter table with audit trail on.

Once an audit trail has been started for a table, the table should not be altered. If you must alter the table, do the following. Copy the table to a backup medium. Use DROP AUDIT to remove the audit trail. Delete the audit-trail file. Alter the table. Again, copy the table to a backup medium. Finally, use CREATE AUDIT to start a new audit trail. The first backup is needed to restore the table if a failure occurs while the table is being altered (a lengthy, disk-intensive procedure if the table is large). The second backup is required because, if the table has to be recovered later, the new audit trail must be applied against a backup that has the same layout of columns.

Oninit® Troubleshooting Guidance

Reasons / Common Causes

-372 protects audit-trail consistency: once a table has an active audit trail, ALTER TABLE against it is blocked outright, because an in-place structural change would break the trail's ability to correctly replay changes against the table's (now different) column structure.

  1. An ALTER TABLE attempted directly against a table with CREATE AUDIT/START AUDIT currently active — the direct, only cause.
  2. A schema migration script written without checking for active audit trails first on the tables it touches.
  3. Forgetting that an audit trail was set up earlier in the table's lifecycle, since auditing configuration isn't always visible from the table's own definition at a glance.
Solutions / Resolution

Per the official guidance, the full required procedure is:

  1. Back up the table — this first backup is a recovery safeguard for the alteration process itself.
  2. Remove the audit trail with DROP AUDIT.
  3. Delete the audit-trail file.
  4. Perform the ALTER TABLE operation.
  5. Create another backup — this second backup matches the table's new (post-alteration) column structure, and is what any future audit-trail-based restoration must be applied against.
  6. Restart the audit trail with CREATE AUDIT.

Skipping either backup, or restarting the audit trail against the wrong backup (the pre-alteration one), will produce the same kind of reconstruction mismatch covered by -343/-344/-345.

Examples
The full procedure
-- 1. Back up the table (via standard backup tooling, not shown here)
-- 2. Remove the audit trail
DROP AUDIT;
-- 3. Delete the audit-trail file at the OS level
-- 4. Perform the alteration
ALTER TABLE orders ADD (shipping_status VARCHAR(20));
-- 5. Take a fresh backup matching the new structure
-- 6. Restart auditing
CREATE AUDIT USING '/informix/audit/audit_trail_new';
Diagnostic Checks
  1. Check whether an audit trail is currently active for the table before attempting ALTER TABLE.
  2. Confirm both backups (before and after the alteration) are taken if proceeding with the full procedure, not just one.
Related Errors / Related Topics
  • -357 — "Dependent table for view view-name has been altered." A related consequence of altering a table — reviewing dependent views is worth doing at the same time as this audit-trail procedure.
  • -338 — "Cannot drop audit trail." A related audit-trail-lifecycle failure that can surface during step 2 of this procedure.

Never skip the second, post-alteration backup — the audit trail can only be restarted correctly against a backup that matches the table's new column structure.