Informix Error -133

Reasons / Common Causes

-133 is a specific, narrow conflict: clustering a file or table is incompatible with an active audit trail, because clustering physically reorders rows — something the audit trail's tracking mechanism can't reconcile with while it's active. The two features are mutually exclusive by design, not by an arbitrary restriction.

1. Attempting to cluster a table that currently has an audit trail enabled. For C-ISAM, this is calling iscluster(); for SQL, it's creating a clustered index. Either one fails outright while the audit trail exists.
2. A maintenance routine attempting periodic re-clustering (to reduce fragmentation or restore physical row order matching a key) on a table that has auditing enabled for compliance or tracking purposes, without checking for this conflict first.
3. Audit trail enabled on a table that already has scheduled clustering maintenance, introducing the conflict going forward without anyone connecting the two features at the time auditing was turned on.
4. Terminology confusion. "Audit trail" here is a specific, narrow C-ISAM/Informix feature for per-file change tracking — not the same thing as a broader compliance-auditing or general logging concept a team might otherwise mean by "auditing." Confusing the two can lead to either unnecessary alarm or an unintended decision about what to disable.
5. Automated schema/index-maintenance tooling that runs the same clustering routine uniformly across many tables without special-casing the ones that happen to have an audit trail enabled.

Solutions / Resolution

1. For C-ISAM programs, call isaudit() with AUDSTOP to disable the audit trail before calling iscluster(). Verify whether stopping and later restarting the audit trail has any implications for continuity of the audit record in your specific compliance context before doing this routinely.
2. For SQL products, use DROP AUDIT to remove the audit trail before creating the clustered index. Note that this removes the audit trail rather than merely pausing it — confirm whether that's acceptable, or capture/export the existing audit data first if it needs to be preserved.
3. For maintenance tooling that clusters many tables routinely, add an explicit check for audited tables and either skip them or perform a controlled disable → cluster → re-enable sequence specifically for the ones that need it.
4. Clarify what "audit trail" refers to in your environment before deciding how to proceed — confirm this is the specific C-ISAM feature and not a broader compliance system, so nothing gets disabled by mistake based on a terminology mix-up.
5. If ongoing compliance requirements make disabling the audit trail undesirable even briefly, reconsider whether clustering this specific table is worth pursuing, or plan the brief audit-trail gap as a documented, approved maintenance window rather than an ad hoc workaround.

Examples

C-ISAM: disabling before clustering

isaudit(fname, AUDSTOP);   /* disable the audit trail first */
iscluster(fd, &keydesc);   /* now valid */

SQL: DROP AUDIT before a clustered index

DROP AUDIT ON ledger;
CREATE CLUSTERED INDEX ledger_date_idx ON ledger (transaction_date);

Confirm before running DROP AUDIT whether the existing audit history needs to be preserved or exported first — this removes the audit trail, it doesn't just pause it.

A maintenance script hitting this unexpectedly

A nightly re-clustering job runs uniformly across a set of tables to control fragmentation; one table in the set had an audit trail enabled recently for a new compliance requirement, and the job starts failing with -133 the next time it runs — the fix is adding an audited-table check to the job, not treating this as a one-off failure to retry.

Diagnostic Checks

1. Check whether an audit trail is currently active for the file/table in question before attempting to diagnose further.
2. Confirm which specific operation is being attempted — iscluster() (C-ISAM) or a clustered-index creation (SQL) — since the resolution differs slightly in mechanism between the two.
3. Confirm compliance or business requirements around the existing audit trail before deciding whether disabling or dropping it is acceptable in this context.

Related Errors / Related Topics

• -100 — "ISAM error: duplicate value for a record with unique key." The other foundational ISAM-level error in this family, though unrelated in cause — grouped here as background on how this error class is organized.

Don't disable or drop an audit trail reflexively to clear this error — confirm what the audit trail is actually protecting and whether removing it (even briefly) is acceptable before proceeding.