Informix Error -205: The statement failed because you cannot use ROWID for views with union, intersect, minus, aggregates, group by, multiple tables, or derived tables.

Reasons / Common Causes

-205 is a structural restriction on ROWID: it's a virtual column that only exists meaningfully for simple tables — a physical row identifier tied to a single, real storage location. Views built from any of several constructs don't have that single-physical-row correspondence, so ROWID can't apply to them.

1. A view based on UNION, INTERSECT, or MINUS — the result combines rows from multiple sources, none of which maps to one physical row location.
2. A view involving aggregate functions or GROUP BY — the resulting rows are computed or summarized, not a direct correspondence to any single physical row.
3. A view joining multiple tables — ROWID is a per-table physical identifier, so it's ambiguous across a multi-table join.
4. A view based on derived tables or subqueries — the same "no single physical row" issue as the other cases.
5. Generic code or ORMs using ROWID as a universal row-identification mechanism, applied uniformly without accounting for which specific views actually support it.
6. A view that used to be a simple pass-through but was later redefined to include one of these unsupported constructs (a UNION added, an aggregate introduced), breaking code that previously relied on ROWID against it.

Solutions / Resolution

1. Query the underlying base table(s) directly instead of the view, per the official guidance, if ROWID access is genuinely needed.
2. Avoid using ROWID against views in generic or ORM code — reserve it for simple, single-table access only, and use an actual primary key or unique constraint for row identification against views instead.
3. If a view was redefined to include one of the unsupported constructs, review any code relying on ROWID against it and update it to use base tables or a different identification strategy.
4. Design row-identification strategies around primary keys or unique constraints rather than ROWID whenever views might be involved — ROWID's applicability is narrower and more fragile to schema changes than a proper key.

Examples

ROWID against a UNION view

CREATE VIEW combined_orders AS
  SELECT * FROM orders_2025
  UNION
  SELECT * FROM orders_2026;

SELECT ROWID FROM combined_orders WHERE order_id = 100;
-- -205: combined_orders is a UNION view — ROWID doesn't apply

Fix — query the correct base table directly:

SELECT ROWID FROM orders_2026 WHERE order_id = 100;

A view that changed underneath existing code

-- Originally a simple pass-through view:
CREATE VIEW active_customers AS SELECT * FROM customer WHERE active = 't';

-- Later redefined to aggregate:
CREATE VIEW active_customers AS
  SELECT region, COUNT(*) AS cnt FROM customer WHERE active = 't' GROUP BY region;

-- Code that used to work now fails:
SELECT ROWID FROM active_customers WHERE region = 'west';
-- -205: the view is now aggregated — ROWID no longer applies

Diagnostic Checks

1. Confirm whether the target object is a simple table or a view, and if a view, what it's actually built from — a union, an aggregate, a join, or a derived table.
2. Review recent view redefinitions that might have introduced one of these unsupported constructs, if code that previously worked has started failing.

Related Errors / Related Topics

• -126 — "ISAM error: bad row id." The other ROWID-related error in this catalogue, though a different mechanism — -126 is about a stale or corrupted physical reference; -205 is about ROWID being structurally inapplicable to certain views at all.
• -201 — "A syntax error has occurred." The general SQL-error family this fits into.

If a view previously supported ROWID and suddenly doesn't, check whether it was recently redefined to include a union, aggregate, join, or derived table — that's almost always the explanation.