Informix Error -857
-857 Rowids do not exist on table.
You cannot drop a nonexistent rowid. You specified a rowid that does not exist in the specified table. Avoid using rowids in your SQL statement. Instead, use a primary key to delete data.
Oninit® Troubleshooting Guidance
Reasons / Common Causes
-857 is the mirror image of -856: it fires when an attempt to drop a table's ROWID column targets one that doesn't currently have one — per the official guidance, you can't drop a nonexistent ROWID, and more broadly, the guidance recommends avoiding reliance on ROWID altogether in favor of a primary key.
ALTER TABLE ... DROP ROWIDSattempted on a table whose ROWID was already dropped, per the official guidance.- A broader design relying on ROWID for row identification/deletion, per the official guidance's own recommendation against this — ROWID values aren't guaranteed stable across reorganizations the way a primary key is.
Solutions / Resolution
- Confirm whether the table already lacks a ROWID column before attempting to drop one:
SELECT ROWID FROM orders WHERE 1 = 0; -- fails if orders currently has no ROWID column - Avoid using ROWID in application SQL at all, per the official guidance's specific recommendation — use a primary key to identify and delete rows instead, since it's a stable, application-controlled identifier rather than an internal storage detail.
Examples
Redesigning around a primary key instead of ROWID
-- Instead of relying on ROWID to delete a specific row:
DELETE FROM orders WHERE order_id = 42;
-- using the table's actual primary key, rather than ROWID
Diagnostic Checks
- Confirm the table's current ROWID status before attempting to drop one.
- Review application SQL for reliance on ROWID, per the official guidance's recommendation, and consider migrating to primary-key-based identification instead.
Related Errors / Related Topics
- -855 — "Cannot drop rowids on a non-fragmented table." A related ROWID-management restriction, about non-fragmented tables specifically.
- -856 — "Rowids already exist on table." The mirror-image situation: attempting to add a ROWID that already exists.
Per the official guidance's own recommendation — avoid relying on ROWID at all; use a primary key for identifying and deleting rows instead.