Informix Error -892

-892 Cannot disable object object-name due to other active objects using it.

Other objects are using this object. If the object being disabled is an index, then a unique constraint, primary constraint, or referential constraint might be using that object. If the object is a unique or a primary-key constraint, then a referential constraint might be using that object. If an index of a referential constraint is being disabled, then a unique constraint, primary constraint, or some other referential constraint might be using this object.

The following example illustrates one of these scenarios:

CREATE TABLE parent(c1 int, c2 int, c3 int); ALTER TABLE parent ADD CONSTRAINT PRIMARY KEY(c1) CONSTRAINT cons_parent_c1; CREATE TABLE child(x1 int, x2 int, x3 varchar(32)); ALTER TABLE child ADD CONSTRAINT PRIMARY KEY(x1) CONSTRAINT cons_child_x1;

The following ALTER statement is trying to disable the foreign key index that is being shared by the primary key, hence this error 892 is returned:

ALTER TABLE CHILD ADD CONSTRAINT (FOREIGN KEY(x1) REFERENCES PARENT(c1) CONSTRAINT cons_child_x2 INDEX DISABLED);

Oninit® Troubleshooting Guidance

Reasons / Common Causes

-892 fires when disabling an object (index, unique/primary-key constraint, or referential constraint's index) would leave a still-active dependent object without what it needs — per the official guidance, three chained dependency scenarios can trigger this, depending on what kind of object is being disabled.

Disabling an index that a unique, primary-key, or referential constraint still depends on, per the official guidance.
Disabling a unique or primary-key constraint that a referential constraint still depends on, per the official guidance.
Disabling a referential constraint's own index while a unique constraint, primary constraint, or another referential constraint still depends on it, per the official guidance — the deepest level of the dependency chain.

Solutions / Resolution

Disable the dependent objects first, working from the outermost dependency inward, before disabling the object actually targeted:
```
SET CONSTRAINTS fk_order_items_orders DISABLED;
SET INDEXES FOR orders DISABLED;
```
(SET INDEXES targets all of a table's user-created indexes via FOR tablename; it doesn't operate on indexes a PRIMARY KEY/FOREIGN KEY constraint created implicitly.)
Identify the full dependency chain before starting, via sysconstraints/sysindexes, to avoid multiple rounds of hitting this error one dependency at a time.

Examples

Disabling a dependent constraint before its underlying index

SET CONSTRAINTS fk_order_items_orders DISABLED;
SET INDEXES FOR orders DISABLED;

Diagnostic Checks

Identify which specific object type is being disabled (index, unique/primary-key constraint, or referential constraint's index), and trace which of the three named dependency patterns applies.
Query sysconstraints/sysindexes for the full dependency chain before starting.

Related Errors / Related Topics

-891 — "Temporary table objects can only be enabled." A related object-mode restriction, specific to temp tables.
-893 — "Cannot activate/create object object-name because of its dependencies." The mirror-image restriction: enabling an object before its own dependencies are enabled.

Disable dependent objects first, working outward-in through the chain, before disabling the object actually targeted.