Informix Error -356

Reasons / Common Causes

-356 is a foreign-key setup restriction: the referencing (child) column's data type must exactly match the referenced (parent) column's data type — Informix doesn't implicitly convert between even closely related types for the purposes of enforcing a foreign key relationship.

1. A referencing column declared with a different type than the referenced column — e.g. the child uses INTEGER while the parent's key is SERIAL, or one uses VARCHAR(20) while the other uses CHAR(20).
2. A schema change to one side of the relationship (widening/narrowing a column, or changing its base type) without updating the other side to match.
3. Copy-pasted table definitions where a column's type was adjusted on one table but not propagated to the corresponding foreign key column on another.
4. Confusing "compatible for comparison" with "identical for a foreign key" — types that would compare or join fine in an ordinary query aren't necessarily acceptable for this constraint.

Solutions / Resolution

1. Match the referencing column's data type exactly to the referenced column's data type, per the official guidance.
2. Check both columns' definitions side by side before defining the constraint:

   SELECT c.colname, t2.name AS type_name
   FROM syscolumns c, systypes t2, systables t
   WHERE t.tabname IN ('orders', 'customers') AND c.tabid = t.tabid
     AND c.coltype = t2.type;
   

3. If a schema change on one side is unavoidable, propagate the same change to the other side of every foreign key relationship involving that column.

Examples

Mismatched types between parent and child

CREATE TABLE customers (
    customer_id SERIAL PRIMARY KEY
);

CREATE TABLE orders (
    order_id INTEGER PRIMARY KEY,
    customer_id VARCHAR(10) REFERENCES customers(customer_id)
);
-- -356: customer_id is SERIAL (effectively INTEGER) on the
-- parent but VARCHAR(10) on the child

Fix — match the types exactly:

CREATE TABLE orders (
    order_id INTEGER PRIMARY KEY,
    customer_id INTEGER REFERENCES customers(customer_id)
);

Diagnostic Checks

1. Compare the exact declared types of both columns in syscolumns/systypes — not just whether they "look" compatible.
2. Check for a recent type change on either the parent or child table if a previously-valid constraint now fails during a schema migration.

Related Errors / Related Topics

• -295 — "Referenced and referencing tables have to be in the same database." Another foreign-key setup restriction in the same general family.
• -297 — "Cannot find unique constraint or primary key on referenced table table-name." Another constraint-setup error in the same family.

Match column types exactly on both sides of a foreign key relationship — "compatible for comparison" in an ordinary query isn't the same bar as what a foreign key constraint requires.