Informix Error -130

Reasons / Common Causes

-130 has two causes worth keeping firmly separate, because they call for completely different responses — the official text itself frames it this way: an everyday naming mismatch (by far the more common case), or genuine root-dbspace corruption (rare, but serious).

The ordinary case — a dbspace name that doesn't exist:

1. A typo or stale reference in a CREATE TABLE's IN clause, an ALTER FRAGMENT statement, or similar DDL naming a dbspace directly.
2. DBSPACETEMP referencing a dbspace name that doesn't exist — a configuration parameter left stale after a dbspace was renamed or removed, or simply misconfigured from the start.
3. A dbspace that existed previously but was dropped (deliberately or by mistake) while application code or configuration still references its name.
4. Environment drift — a script or application config hardcoding a dbspace name that's valid in one environment (production) but was never created in another (development, staging) where the full dbspace layout wasn't replicated.
5. A restore or migration that didn't fully recreate the original dbspace layout, leaving a reference to a dbspace name the restored environment doesn't actually have.

The rare, more serious case — root dbspace corruption:

6. If the dbspace name given is correct, or no name was explicitly specified at all, and the dbspace genuinely should exist, the official text names corruption of reserved pages in the root dbspace as the underlying cause — a much more serious engine-level condition than a simple naming mismatch.

Solutions / Resolution

1. Run onstat -d first, always — this shows the actual list of existing dbspaces and is the fastest way to distinguish "this name genuinely doesn't exist" (the ordinary case) from "this name should be there and isn't showing up correctly" (worth investigating further as the rarer case).
2. If the dbspace genuinely doesn't exist and is needed, have the database administrator create it.
3. Fix the specific typo or stale reference in the DDL, script, or DBSPACETEMP configuration once identified.
4. For environment drift, ensure dbspace layout is consistently replicated across environments, or make scripts/configuration environment-aware rather than hardcoding names that only exist in one place.
5. If the name is correct (or wasn't explicitly given) and onstat -d doesn't resolve the confusion, treat this as the more serious case: run

   oncheck -cr
   

   (or tbcheck -cr on older OnLine versions) to check for corruption of reserved pages in the root dbspace.
6. If corruption is confirmed, treat it as a serious engine-level issue and escalate to IBM Informix Technical Support — the root dbspace's central role in the engine makes this a different category of problem from an ordinary naming mismatch.

Examples

The ordinary typo

CREATE TABLE customer (id INT, name VARCHAR(50)) IN customar_ds;
-- -130: "customar_ds" doesn't exist — the intended dbspace is "customer_ds"

onstat -d
-- confirms customer_ds exists; customar_ds does not

DBSPACETEMP misconfiguration

DBSPACETEMP  tempdbs1,tempdbs2

If tempdbs2 was dropped or renamed since this onconfig setting was written, any operation needing temporary space can fail with -130 the moment it tries to use the missing entry — onstat -d against the current configuration reveals the mismatch immediately.

Environment drift

A deployment script hardcodes IN prod_archive_ds for an archival table, and runs correctly in production where that dbspace exists — then fails with -130 the first time the same script runs in a staging environment that only ever replicated the primary dbspaces, not the archival one.

Diagnostic Checks

1. List current dbspaces:

   onstat -d
   

2. Review the exact DDL, script, or configuration naming the missing dbspace, and compare it character-for-character against the actual list.
3. If the name appears correct or wasn't explicitly given, check for root dbspace corruption:

   oncheck -cr
   

4. Compare dbspace configuration across environments if the failure is specific to one environment and not others running ostensibly the same code/config.

Related Errors / Related Topics

• -100 — "ISAM error: duplicate value for a record with unique key." The other foundational ISAM-level error in this family.
• -105 — "ISAM error: bad ISAM file format." Similar structure to -130's rarer cause — both can indicate genuine corruption requiring the appropriate check utility, though -130's ordinary case (a naming mismatch) is far more common than -105's causes tend to be.

Run onstat -d before anything else — it resolves the overwhelming majority of -130 reports immediately, and its absence of a resolution is itself the signal to move to the corruption investigation instead.