Informix Error -244: Could not do a physical-order read to fetch next row.
Cause and resolution
Could not do a physical-order read to fetch next row.
The database server cannot read the disk page that contains a row of a table. Check the accompanying ISAM error code for more information. A hardware problem might exist, or the table or index might have been corrupted. If the query was using the dirty read isolation level, this error code may be normal behavior caused by reading data that was in a temporarily inconsistent state from a concurrent update on the same data.
Unless the ISAM error code or an operating-system message points to another cause, run the oncheck utility (secheck with IBM Informix SE or tbcheck with IBM Informix OnLine) to check and repair table and index.
Oninit® Troubleshooting Guidance
Reasons / Common Causes
-244 has the same dual-cause shape as -126 and -164: it can mean genuine corruption, or it can be normal behavior under Dirty Read isolation racing a concurrent update. The official text is explicit about both possibilities for this specific error.
- A hardware problem preventing the disk page containing the row from being read.
- Table or index corruption.
- Dirty Read isolation racing a concurrent update on the same data. The official text states this "may be normal behavior" — reading data in a temporarily inconsistent state because another session is actively updating it — not a sign of anything actually broken.
Solutions / Resolution
- Check the accompanying ISAM error code and OS-level messages first.
- If using Dirty Read isolation, consider whether this is expected given known concurrent update activity on the same data — the same "reread and see if it resolves" approach as -126/-164 applies here.
- If not explained by Dirty Read timing, run
oncheck(secheckfor SE,tbcheckfor OnLine) to check and repair the table and index, per the official guidance.
Examples
Dirty Read timing
SET ISOLATION TO DIRTY READ;
SELECT * FROM inventory WHERE sku = 'WIDGET-1';
-- -244 if this races a concurrent update physically relocating
-- or modifying the page being read — expected under Dirty Read
Confirming genuine corruption
oncheck -cd mydb:inventory
Run this once Dirty Read timing has been ruled out or found not to explain the failure.
Diagnostic Checks
- Check the accompanying ISAM error code and OS-level messages.
- Check the isolation level in use for the failing query — Dirty Read is the first thing to rule in or out.
- Run
oncheck/secheck/tbcheckif the timing explanation doesn't apply.
Related Errors / Related Topics
- -126 — "ISAM error: bad row id." The closest sibling in structure — same Dirty-Read-vs- corruption dual cause.
- -164 — "ISAM error: TEXT or BYTE stamp is incorrect." Another sibling with the identical dual-cause pattern, applied to large object data specifically.
Check the isolation level first — if this is Dirty Read racing a concurrent update, it's expected behavior, not corruption to investigate.