Informix Error -886

-886 Cannot drop table or view because of existing dependencies.

When you issue a DROP TABLE or DROP VIEW statement, you cannot drop the table or view if you specify the RESTRICT option and a view or foreign-key constraint exists that depends on that table or view.

You also cannot drop a table if you specify the RESTRICT option and a violations and diagnostics table exists for that table.

Oninit® Troubleshooting Guidance

Reasons / Common Causes

-886 fires when DROP TABLE/DROP VIEW ... RESTRICT targets an object that other objects still depend on — per the official guidance, three specific dependency types block it: a dependent view, a dependent foreign-key constraint, or (for a table specifically) an associated violations and diagnostics table.

A view built on the table/view being dropped, per the official guidance — RESTRICT specifically blocks the drop when a dependent view exists.
A foreign-key constraint referencing the table being dropped, per the official guidance — the same underlying dependency as -692's ordinary row-level referential-integrity check, here applying at the schema (DDL) level.
A violations and diagnostics table associated with the table being dropped, per the official guidance — a table-specific dependency type, for tables that have this error-tracking mechanism enabled.

Solutions / Resolution

Drop the dependent view(s) first, if the table/view being dropped is the intended target and dependent views aren't needed:
```
DROP VIEW recent_orders_view;
DROP TABLE orders RESTRICT;
```
Drop the dependent foreign-key constraint(s) first, per the same approach as -784/-692's resolution, if a foreign key is what's blocking the drop.
Drop the associated violations and diagnostics table first, if that's the specific dependency blocking a table drop.
Or use CASCADE instead of RESTRICT (or omit the option, depending on the server's default), if automatically dropping all dependents along with the table/view is actually intended — confirm the exact default/CASCADE behavior for the server version in use before relying on it, since dropping dependents automatically is a more consequential operation.

Examples

Dropping a dependent view first

DROP VIEW recent_orders_view;
DROP TABLE orders RESTRICT;

Checking for dependent foreign keys

SELECT c.tabname AS referencing_table, k.constrname
FROM sysreferences r, sysconstraints k, systables c
WHERE r.constrid = k.constrid
  AND k.tabid = c.tabid
  AND r.ptabid = (SELECT tabid FROM systables WHERE tabname = 'orders');
-- lists foreign-key constraints, on other tables, that reference orders

Diagnostic Checks

Check for dependent views, foreign-key constraints, and (for tables) an associated violations and diagnostics table, the three specific dependency types the official guidance names.

Related Errors / Related Topics

-784 — "Cannot detach because of the existing referential constraints." A related referential-constraint-dependency restriction, in the ALTER FRAGMENT ... DETACH context rather than DROP TABLE/DROP VIEW.
-692 — "Key value for constraint constraint-name is still being referenced." A related referential-integrity restriction, at the row-delete level rather than schema-level DROP.

Three specific dependency types block a RESTRICT-qualified drop — check for dependent views, foreign keys, and (for tables) a violations and diagnostics table.