Informix Error -869

Reasons / Common Causes

-869 fires when a fragmentation expression includes a subquery or a procedure/function call — per the official guidance, a fragmentation expression can only reference columns from the current table and data values from a single row, the same underlying principle as -677's check-constraint restriction.

1. A fragmentation expression including a SELECT subquery, per the official guidance — the fragment a row belongs to must be determinable from that row alone, not by querying other data.
2. A fragmentation expression calling a user-defined function/procedure, per the official guidance — even a side-effect-free function is disallowed, since fragment assignment needs to be a pure, single-row computation.

Solutions / Resolution

1. Remove the subquery or procedure call from the fragmentation expression, per the official guidance — express the fragment-assignment rule using only the row's own column values and built-in, non-query expressions.
2. If fragment assignment genuinely depends on other data, compute a derived column at insert/update time (application-level) and fragment on that derived column instead — the same general workaround pattern used for -677's check-constraint restriction.

Examples

The disallowed subquery

CREATE TABLE orders (order_id INT, customer_id INT, region CHAR(10))
  FRAGMENT BY EXPRESSION
  (customer_id IN (SELECT customer_id FROM vip_customers)) IN vip_dbspace,
  REMAINDER IN standard_dbspace;
-- -869: subquery in a fragmentation expression

Corrected — fragment on a derived column instead

CREATE TABLE orders (order_id INT, customer_id INT, region CHAR(10), is_vip CHAR(1))
  FRAGMENT BY EXPRESSION
  (is_vip = 'Y') IN vip_dbspace,
  REMAINDER IN standard_dbspace;
-- is_vip populated at the application level based on customer_id's VIP status

Diagnostic Checks

1. Scan the fragmentation expression for a SELECT subquery or a function/procedure call, and redesign using a derived column populated at the application level instead.

Related Errors / Related Topics

• -677 — "Check constraint cannot contain subqueries or procedures." The same underlying single-row-evaluation principle, applied to CHECK constraints rather than fragmentation expressions.

The same single-row-evaluation principle as -677's check-constraint restriction — fragment on a derived column populated at the application level instead of a subquery or function call.