Informix Error -109

Reasons / Common Causes

-109 means an isdelindex() call targeted the file's primary key — the key defined first when the file was created with isbuild() — and the library refuses unconditionally. There's no flag or special case that permits it; a C-ISAM file's primary key cannot be dropped in place, full stop. Every realistic cause traces back to code reaching key 0 when it shouldn't have:

1. A generic "rebuild all indexes" maintenance routine that enumerates every key defined on a file and calls isdelindex() on each one, without excluding key 0. This is the single most common path to -109 — the routine works fine for every secondary key and only fails once it reaches the primary.
2. Confusing C-ISAM's "primary key" with an application's business primary key. At this layer, "primary key" specifically means "the first key defined at file-creation time" — it's a structural, positional concept, not necessarily the column set a developer would call the primary key in SQL terms. Code that means to target "some other index" can hit key 0 by miscounting or by a stale assumption about key ordering.
3. A migration or porting tool modeling "drop primary key, define a different one" as two direct ISAM calls — isdelindex() on the old primary key followed by isaddindex() for the new definition. This specific sequence isn't supported at the C-ISAM level regardless of what the second call would have defined; the primary key is fixed for the life of the file as isbuild() created it.
4. SQL-level primary key changes implemented incorrectly by application code that drops to the ISAM API directly, rather than going through ALTER TABLE ... DROP CONSTRAINT / ADD CONSTRAINT PRIMARY KEY, which the engine itself knows how to translate into the necessary file-level rebuild — a raw isdelindex() on the primary key is not the equivalent operation.

Solutions / Resolution

1. Don't call isdelindex() on the primary key. There's no workaround at this level — the restriction is structural, not a permissions or flag issue.
2. If the actual goal is to change the primary key definition, that requires re-creating the file: isbuild() a new file with the desired primary key, migrate the data across, and swap the new file in for the old one — not an in-place delete-and-redefine of the existing file's primary key.
3. For SQL-level primary key changes, use the engine's own DDL:

   ALTER TABLE customer DROP CONSTRAINT pk_customer;
   ALTER TABLE customer ADD CONSTRAINT PRIMARY KEY (new_key_column) CONSTRAINT pk_customer;
   

   and let the engine manage the necessary rebuild internally, rather than an application issuing raw isdelindex()/isaddindex() calls against the underlying file directly.
4. In maintenance/rebuild tooling that iterates over all keys, explicitly skip key 0 (the primary key) unless the actual intent is a full file rebuild — which needs the create-new, migrate, swap-in approach from #2, not a delete-then-add cycle targeting the same key number.
5. Clarify "primary key" terminology on the team if this keeps recurring — the gap between "the first key C-ISAM defined" and "our application's business primary key" is a common source of code that targets the wrong key number.
6. If -109 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 blind "rebuild all indexes" loop

for (keyno = 0; keyno < num_keys; keyno++) {
    isdelindex(fd, keyno);
    isaddindex(fd, &keydescs[keyno]);
}
/* -109 the moment keyno reaches 0 — the primary key */

The fix is to skip key 0 in this loop, and handle a genuine primary-key rebuild through the create-new-file approach instead, not by extending this same loop to somehow succeed against it.

Mistaking "primary key" for "the index I meant"

/* Developer intends to drop what they think of as the file's "main"
   unique index, assuming it's whatever they defined most recently */
isdelindex(fd, 0);
/* -109: key 0 is the file's actual primary key (the first one ever
   defined via isbuild()), not whichever index the developer had in mind */

Checking the file's actual key layout (see Diagnostic Checks) before assuming which key number corresponds to which index avoids this class of mistake.

The unsupported redefine-in-place attempt

/* Attempting to change the primary key definition without recreating the file */
isdelindex(fd, 0);           /* -109 immediately, nothing after this runs */
isaddindex(fd, &new_pk_keydesc);

Correct approach:

/* Build a new file with the desired primary key, then migrate data in
   and swap the new file in for the old one — the primary key can't be
   changed on the existing file at all */
newfd = isbuild("customer_new", RECORDLEN, &new_pk_keydesc, ISINOUT);
/* ... copy records from the old file into customer_new ... */
/* ... rename customer_new into place once migration is verified ... */

Diagnostic Checks

1. Identify which key number the failing call targeted, and confirm it's actually key 0:

   /* iserrno == -109 confirms it, but log the keyno argument itself
      at the call site to be certain which index was actually targeted */
   

2. Review the file's actual key layout rather than assuming key numbering from memory:

   isindexinfo(fd, &keydesc, 0);   /* key 0 is always the primary key */
   

3. Review maintenance/rebuild tooling logic for whether it special-cases or excludes the primary key when iterating over all keys on a file.
4. Check whether the failing call originated from application code calling the ISAM API directly, or was reached via SQL DDL — if the latter, this may be an engine-internal issue worth escalating rather than an application bug to fix.

Related Errors / Related Topics

• -100 — "ISAM error: duplicate value for a record with unique key." The other foundational ISAM-level error in this family.
• -108 — "ISAM error: key already exists." The sibling error in index definition management — -108 is trying to create a key structure that already exists; -109 is trying to remove one (the primary key specifically) that the library refuses to let go. Both are usually a maintenance-tooling logic gap rather than a data problem.

If you're trying to change what a file's primary key is, not just remove an index, see Solutions #2 — that's a file re-creation, never an in-place operation on the existing file.