Informix Error -135

Reasons / Common Causes

-135 is one of the more serious errors in this range. The official text doesn't offer an everyday, ordinary explanation the way -130 does for a simple naming mismatch — it points directly at possible corruption of control information in the root dbspace, and says plainly that recovery might require restoring the system from archive. Treat it with that weight from the start rather than searching for a routine cause first.

1. Corruption of control information in the root dbspace — the tblspace tblspace (the engine's own bookkeeping about where every other tblspace lives) has become damaged, so a reference to a tblspace that should exist can't be resolved.
2. An unclean shutdown or crash mid-write to root dbspace structures specifically — the same general corruption pathway as -105, but affecting the engine's most central metadata rather than an individual table or index.
3. Hardware failure or disk errors affecting the storage underlying the root dbspace.
4. An improperly taken "hot" copy or backup of the root dbspace chunk while writes were in progress, capturing an internally inconsistent snapshot.
5. External tooling or manual intervention touching root dbspace chunk files directly, outside the engine's own management.
6. A restore that didn't correctly reconstruct root dbspace control structures.
7. A version mismatch or an unsupported upgrade path leaving root dbspace metadata in a format the current engine version misinterprets.
8. Less catastrophically: a dropped table or tblspace from an incomplete or interrupted DDL operation, leaving a dangling reference to a tblspace entry that no longer resolves — possible, but the official guidance's own framing suggests genuine corruption is the more likely explanation to check for first.

Solutions / Resolution

Follow the official guidance's sequence directly — this isn't a condition to keep probing application-side before escalating:

1. Roll back the current transaction and terminate the application immediately. Don't continue attempting operations against a database server in this state.
2. Have the database server administrator run the appropriate check/repair utility — tbcheck, oncheck, or onutil depending on version — to assess and attempt repair of the root dbspace's control structures.
3. If repair isn't possible, be prepared to restore the system from archive. The official text names this as a real possibility for this specific error, not a remote worst case to dismiss — verify recent backups are actually usable before you need them.
4. After recovery, investigate root cause rather than treating the restore as the end of the incident: check for a recent unclean shutdown, hardware issues on the storage underlying the root dbspace, any manual or external tooling that touched dbspace chunk files, or a recent restore/migration that might not have completed correctly.
5. Confirm regular, verified backups exist going forward. This is exactly the failure mode where backup discipline is what determines whether the incident is a repair or a full restoration.
6. If a version mismatch or upgrade issue is suspected, confirm the upgrade was performed through the documented, supported path rather than an ad hoc method.

Examples

The immediate response sequence

ROLLBACK WORK;

-- Terminate the application connection, then have the administrator run:
tbcheck -y     -- or oncheck / onutil, per the version in use

This is not a sequence to skip past in search of a faster fix — per the official guidance, it's the correct first response regardless of what eventually turns out to have caused it.

Investigating after recovery

grep -iE "abort|panic|shutdown" $INFORMIXDIR/online.log
dmesg -T | grep -iE "error|i/o|reset"

Once the immediate incident is handled, correlating the timing against a crash, an I/O error, or a recent restore/migration is what determines whether this is likely to recur — don't close the incident without this step.

Diagnostic Checks

1. Run the version-appropriate check/repair utility first, as the official guidance specifies:

   tbcheck -y
   oncheck -cc
   onutil
   

2. Check the message log for related errors around when this first appeared:

   grep -iE "abort|panic|shutdown|assert" $INFORMIXDIR/online.log
   

3. Check OS/storage logs for hardware or I/O errors affecting the root dbspace's underlying storage.
4. Review recent operational history — crashes, restores, migrations, or any external tooling that touched dbspace chunk files — for anything coinciding with the failure's likely onset.

Related Errors / Related Topics

• -105 — "ISAM error: bad ISAM file format." The closest sibling in severity and cause — both point at genuine corruption requiring a check/repair utility and, potentially, a restore from backup.
• -130 — "ISAM error: no such dbspace." A much more common, much less serious condition reached from a similar direction (a dbspace-related reference that doesn't resolve) — -130 is usually a simple naming mismatch; -135 is the far more serious case where the engine's own central bookkeeping may be damaged.

Don't spend time searching for an application-level explanation before running the check utility — per the official guidance, this specific error is serious enough that verifying (or ruling out) root dbspace corruption comes first.