Informix Error -112

Reasons / Common Causes

-112 is more of a genuine program-logic bug than -110/-111 — it means isread() was called with the ISCURR retrieval mode before any earlier call established what "current" even refers to. ISCURR asks "give me the record the file is already positioned at"; if nothing has positioned it yet, there's nothing to return.

1. ISCURR used as the very first read against a freshly opened file, with no preceding ISFIRST, ISLAST, ISEQUAL, ISGREATEQ, or similar positioning call. This is the direct case the official text describes.
2. ISCURR called right after a failed prior read. A read that returned an error (-110, -111, or anything else) does not establish a current record — calling ISCURR next has nothing to work with, even though some read attempt did happen just before it.
3. Position not carried across a close/reopen cycle. Closing and reopening a file resets its position state; code that assumes the previous handle's "current record" survives into a new isopen() call is mistaken.
4. Confusion in multi-file-descriptor code — treating "current record" as shared/global state when it's actually per-file-descriptor, and issuing ISCURR against a descriptor that never had a positioning call run against it specifically.
5. A regression from refactoring — code that reorders or restructures retrieval logic and accidentally drops the initial positioning call that used to run before ISCURR, without anyone noticing until this error appears.
6. Positioning invalidated by a delete — depending on the specific behavior in use, deleting the current record can leave the file without a well-defined "current" position for a subsequent ISCURR until something repositions it.

Solutions / Resolution

1. Always perform an initial positioning read — ISFIRST, ISLAST, ISEQUAL, ISGREATEQ, or similar — before the first ISCURR call on a given file descriptor. Review the retrieval logic's call order explicitly rather than assuming it's correct.
2. Check the return value of every read, including the one meant to establish position. If that read failed, don't proceed to ISCURR — there's nothing current to fetch, and the resulting -112 would just be masking the earlier failure.
3. Re-establish position after every isclose()/isopen() cycle — never assume position state survives a close, even briefly.
4. In code juggling multiple file descriptors, track "has positioning happened yet?" per descriptor explicitly, rather than relying on an assumption that it's a single shared state.
5. After deleting the current record, check what the specific behavior requires for continued positioning, and reposition explicitly before another ISCURR if needed.
6. When refactoring retrieval code, keep the positioning call and the following ISCURR calls visibly paired — consider a helper function that always performs both together, so a future refactor can't separate them without it being obvious.

Examples

The missing initial positioning call

int fd = isopen("customer", ISINPUT);
isread(fd, &record, ISCURR);   /* -112: nothing has positioned this file yet */

Correct version:

int fd = isopen("customer", ISINPUT);
isread(fd, &record, ISFIRST);  /* establishes position */
/* ... later ... */
isread(fd, &record, ISCURR);   /* now valid */

ISCURR after an unchecked failed read

isread(fd, &record, ISEQUAL);   /* fails — record doesn't exist, iserrno == -111 */
/* return value not checked */
isread(fd, &record, ISCURR);    /* -112: the ISEQUAL failed, so there is no current record */

The real bug is not checking the first call's return value — -112 here is a downstream symptom, not the actual defect.

Lost position across a reopen

int fd = isopen("customer", ISINPUT);
isread(fd, &record, ISEQUAL);
isclose(fd);

fd = isopen("customer", ISINPUT);   /* new handle — position from before is gone */
isread(fd, &record, ISCURR);        /* -112 */

Position doesn't carry across the close/reopen — the new handle needs its own positioning call.

Diagnostic Checks

1. Review the call sequence immediately before the failing ISCURR — was there a positioning call (ISFIRST/ISLAST/ISEQUAL/ISGREATEQ) on the same file descriptor, and did it succeed?
2. Check the return code of that prior positioning call explicitly — a failure there, unchecked, is the most common actual root cause behind a -112 that "seems to come from nowhere."
3. In multi-descriptor code, confirm which fd the failing ISCURR targets and whether positioning was established on that exact descriptor, not just on some other open handle to the same file.
4. Review recent changes to the retrieval logic — a refactor that reordered or split apart positioning and retrieval calls is a common way to introduce this regression.

Related Errors / Related Topics

• -100 — "ISAM error: duplicate value for a record with unique key." The other foundational ISAM-level error in this family.
• -111 — "ISAM error: no record found." Closely related in practice: a -111 from an unchecked positioning call is one of the most common actual causes of a subsequent -112 — check for that sequence first before treating -112 as an isolated problem.

If -112 appears without an obvious missing positioning call in the code you're looking at, check whether the call that should have positioned the file failed silently first — that's the most common real explanation.