Informix Error -194

Reasons / Common Causes

-194 is the chunk-level counterpart to -148: a chunk still holds data (tables, indexes, or fragments) and can't be dropped until that data is relocated or removed.

1. The specific chunk being dropped still contains table, index, or fragment data — the direct cause.
2. A dbspace with multiple chunks where other chunks are empty, but the one being targeted for removal isn't — occupancy has to be checked per chunk, not assumed from the dbspace's aggregate free space.
3. Assuming a chunk is empty after "moving" data away from it, without verifying — the same fragment-left-behind risk -148 describes, applied here at chunk granularity.
4. Attempting to shrink a dbspace by removing a non-first chunk without first confirming no data actually resides on that specific chunk.

Solutions / Resolution

1. Use the appropriate check utility to identify what's still on the chunk, before attempting to drop it:

   oncheck -pe <database>:<dbspace>
   

   The same diagnostic step -148 recommends, applied at chunk granularity rather than the whole dbspace.
2. Relocate or drop the data/fragments residing on that specific chunk before attempting to drop it.
3. For dbspace-shrinking efforts, verify per-chunk occupancy directly — don't assume a chunk is empty just because the dbspace's aggregate free space looks sufficient.

Examples

Checking chunk-level occupancy before dropping

oncheck -pe mydb:dbspace1
-- reveals chunk2 still holds a fragment of the "orders" table,
-- even though chunk1 and chunk3 in the same dbspace are empty

Dropping chunk2 fails with -194 until that fragment is relocated or dropped — the fix is addressing that specific data, not assuming the dbspace's overall low usage means every individual chunk is clear.

A shrink attempt that assumed too much

A team trying to shrink a dbspace by removing its least-recently-added chunk assumes it's empty because the dbspace overall has plenty of free space — but the specific chunk being targeted still holds an active fragment. Checking with oncheck -pe before attempting the drop avoids the failed attempt entirely.

Diagnostic Checks

1. Run oncheck -pe against the dbspace to see exactly what resides on each chunk.
2. Cross-check any migration or consolidation plan against actual per-chunk occupancy, rather than the dbspace's aggregate free space.

Related Errors / Related Topics

• -148 — "ISAM error: dbspace is not empty." The same structural precondition, one level up — applied to an entire dbspace rather than a single chunk within one.
• -192 — "ISAM error: Cannot drop first chunk." The other chunk-drop-restriction sibling, though a structural rule rather than a data-occupancy one.

Run oncheck -pe first, always — it turns "why won't this chunk drop?" into a specific, actionable list of what's still there, exactly as it does for a whole dbspace under -148.