Informix Error -888

Reasons / Common Causes

-888 fires when ALTER FRAGMENT ... ATTACH is attempted while a primary-key or unique constraint exists on either the surviving table or the consumed (attaching) table — per the official guidance, both must be dropped before the attach, the same general pattern as -868's check/referential/NOT NULL constraint restriction.

1. A primary-key or unique constraint present on the surviving table, per the official guidance.
2. A primary-key or unique constraint present on the table being attached, per the official guidance — this restriction covers both sides, unlike -868 which is specific to the surviving table.

Solutions / Resolution

1. Drop the primary-key (or unique) constraint on whichever table(s) have one, per the official guidance:

   ALTER TABLE orders DROP CONSTRAINT PRIMARY KEY;
   ALTER TABLE orders_2025 DROP CONSTRAINT PRIMARY KEY;
   

2. Attach the table, per the official guidance, once both sides are clear.
3. Re-create the constraint afterward if still needed, per the official guidance:

   ALTER FRAGMENT ON TABLE orders ATTACH orders_2025;
   ALTER TABLE orders ADD CONSTRAINT PRIMARY KEY (order_id);
   

Examples

Drop, attach, re-create

ALTER TABLE orders DROP CONSTRAINT PRIMARY KEY;
ALTER FRAGMENT ON TABLE orders ATTACH orders_2025;
ALTER TABLE orders ADD CONSTRAINT PRIMARY KEY (order_id);

Diagnostic Checks

1. Query sysconstraints for primary-key/unique constraints (constrtype = 'P' or 'U') on both the surviving table and the table(s) being attached before attempting the operation.

Related Errors / Related Topics

• -868 — "Cannot check constraints on the attaching table." A related ATTACH-prerequisite restriction, for check/referential/NOT NULL constraints on the surviving table specifically.
• -864 — "Cannot attach a table with rowids." Same general family of ATTACH-prerequisite restrictions.

Same drop-attach-recreate pattern as -868, here for primary-key/unique constraints on either side of the attach.