Informix Error -148

Reasons / Common Causes

-148 is a straightforward precondition failure: a dbspace can't be dropped while it still contains tables. Every cause traces back to something still residing in the dbspace that the person attempting the drop didn't account for.

1. The dbspace genuinely still has one or more tables in it, and the drop was attempted before removing them — the direct case.
2. Incomplete knowledge of what's actually in the dbspace — not accounting for table fragments specifically. A table primarily stored elsewhere can still have a fragment or an index piece in the dbspace being dropped, even if the "main" data was already moved.
3. Decommissioning a dbspace as part of a migration or consolidation without first confirming and completing the migration of every object out of it — the plan called for it to be empty, but execution didn't fully match the plan.
4. A table thought to already be dropped, but actually still present — a DROP TABLE that failed partway, was never actually executed, or was rolled back without anyone noticing.
5. Indexes or other objects still referencing the dbspace even after primary table data was relocated — possible if only part of a migration was carried out.

Solutions / Resolution

1. Use oncheck -pe (or tbcheck -pe on older versions) to identify every object still residing in the dbspace before attempting to drop it — this is the official guidance's own recommended first step, and it's the fastest way to see exactly what's blocking the drop.
2. Drop or relocate every remaining table (and any fragments) out of the dbspace.
3. Verify no indexes, temp tables, or other objects still reference the dbspace before retrying the drop.
4. For migration/consolidation projects, make "confirm the dbspace is genuinely empty via oncheck -pe" an explicit checklist step before attempting removal — don't rely on the migration plan's intent alone.
5. If a DROP TABLE was expected to have already run and apparently didn't, investigate why (a permissions issue, a failed or rolled-back transaction) before simply retrying the dbspace drop.

Examples

Checking what's actually left

oncheck -pe mydb:old_dbspace

Run this before attempting the drop, not after it fails — it lists exactly what still needs to be removed or relocated, turning a guessing exercise into a direct checklist.

A fragment left behind after "moving" a table

-- A table was fragmented across two dbspaces
-- The migration moved the primary fragment but missed a secondary one

oncheck -pe mydb:old_dbspace
-- reveals a fragment of "orders" still present, even though the
-- "main" data was believed to have been fully relocated

The drop fails not because the migration was entirely incomplete, but because one fragment among several was overlooked.

DROP TABLE that didn't actually run

A decommissioning script assumes a preceding DROP TABLE step succeeded and proceeds straight to dropping the dbspace — if that earlier step actually failed silently (a permissions issue, a transaction that rolled back), the dbspace drop fails here with a clear, checkable reason rather than leaving the earlier failure unnoticed.

Diagnostic Checks

1. Run oncheck -pe against the dbspace to list every remaining table or object:

   oncheck -pe <database>:<dbspace>
   

2. Cross-check the migration/decommission plan against the actual list returned, rather than assuming the plan was fully executed.
3. Check specifically for table fragments, not just whole tables, if the dbspace was ever part of a fragmented table's storage.

Related Errors / Related Topics

• -100 — "ISAM error: duplicate value for a record with unique key." The other foundational ISAM-level error in this family.
• -130 — "ISAM error: no such dbspace." The naming-mismatch sibling in dbspace lifecycle management — -130 is trying to reference a dbspace that doesn't exist; -148 is trying to remove one that still exists and still has content in it.

Run oncheck -pe first, always — it turns "why won't this dbspace drop?" into a specific, actionable list rather than a guessing exercise.