Informix Error -127: ISAM error: no primary key.

Reasons / Common Causes

-127 means a function that requires a unique primary-key index was called against a file that doesn't have one. The official text is specific about the most common legitimate reason: the file may have been deliberately created with a zero-part primary index — designed for retrieval purely by record-number sequence, not by key. That's a valid design choice, not a defect, and it's worth ruling in before assuming anything is broken.

1. The file was intentionally created with a zero-part primary index. Some ISAM files are designed for sequential, record-number-based access only (isbuild() with a zero-part keydesc) — no keyed primary index was ever meant to exist. A function that requires one simply isn't compatible with this file by design, not by accident.
2. Generic or shared code assuming every file has a primary key. Application code written to operate across multiple ISAM files, without accounting for the specific files that were deliberately built without a keyed primary index, calls a keyed function against one of the exceptions.
3. Index metadata damage. Independent of the zero-part-by-design case, the official text names damaged index metadata as the other realistic explanation — the file was supposed to have a working primary key index, and something has corrupted the structure that would represent it.
4. A new feature or refactor introducing a call path that requires a primary key on a file that was never designed with one — the file's original design was correct for its original purpose; the new code path is what's incompatible with it.

Solutions / Resolution

1. Confirm the file's actual design intent first. If it was deliberately built with a zero-part primary index for record-number access, the fix is not to call the primary-key-requiring function against this file at all — use record-number-based alternatives instead of key-based ones for this specific file.
2. If a real primary key is genuinely needed going forward (a legitimate design change), recreate the file with an actual primary key index via isbuild(), migrating existing data across — this can't be added to the existing file in place.
3. If the file was supposed to have a working primary key and doesn't, and this isn't an intentional zero-part design, investigate index damage: run bcheck/secheck against the file.
4. For generic or shared library code spanning many ISAM files, gate or special-case functionality that requires a primary key so it fails gracefully (or isn't offered at all) for files that were deliberately designed without one.
5. If -127 recurs with none of the above explaining it, document the full circumstances and escalate to IBM Informix Technical Support, per the official guidance.

Examples

The deliberate zero-part design, misapplied

/* This file was intentionally built for record-number access only */
struct keydesc kd = { .k_nparts = 0 };
int fd = isbuild("audit_log", RECORDLEN, &kd, ISINOUT);

/* Later, generic library code assumes every file has a primary key */
isstart(fd, 0, &search_key, ISEQUAL);
/* -127: audit_log has no primary key index — it was never meant to */

The fix is in the generic code's assumption, not in audit_log's design — this file was correct as built; the calling code needs to either skip it or use record-number-based access instead.

Damaged index metadata

bcheck audit_log

Run this when a file that should have a real primary key reports -127 unexpectedly — if the utility finds and repairs damage, that confirms this was corruption rather than an intentional zero-part design.

Diagnostic Checks

1. Review the file's original isbuild() call or key descriptor definition to confirm whether a zero-part primary index was the intentional design.
2. Run bcheck/secheck to rule out index damage if the zero-part design doesn't explain it.
3. Review the calling code path to confirm whether it's actually appropriate to invoke against this specific file — especially for generic or shared library code operating across multiple ISAM files with different designs.

Related Errors / Related Topics

• -100 — "ISAM error: duplicate value for a record with unique key." The other foundational ISAM-level error in this family.
• -109 — "ISAM error: the key is the file's primary key." Both concern the C-ISAM concept of a file's primary key specifically — -109 is about being unable to remove it; -127 is about a function needing one that doesn't exist at all (whether by design or by damage).

Before assuming a file needs a primary key added, confirm whether its zero-part design was intentional — a large share of -127 reports are generic code encountering a deliberately different kind of file, not a defect in the file itself.