Informix Error -204

Reasons / Common Causes

-204 is the floating-point counterpart to -203's integer validation: a numeric constant punctuated like a floating-point number (a decimal point and/or an exponent starting with e) isn't acceptable — often because the exponent is too large to process.

1. An exponent too large to be represented — a value like 1e400 exceeding the representable range for the floating-point type.
2. Malformed floating-point syntax — multiple decimal points, a decimal point combined with a malformed exponent, or other punctuation errors in what was intended to be a floating-point constant.
3. A value from a calculation or external data source producing an extreme magnitude — a numeric overflow or underflow in application code, formatted as a floating literal and embedded directly into generated SQL.
4. Locale/formatting mismatches — a language or system using a different decimal separator (a comma instead of a period) generating a malformed literal when directly embedded into SQL text.
5. Auto-generated SQL that doesn't validate the format or magnitude of floating-point values before embedding them as literals.

Solutions / Resolution

1. Inspect the constant for a valid decimal-point/exponent format, per the official guidance, and correct malformed punctuation.
2. If the exponent is too large, check whether the underlying value is actually correct. A legitimate but extreme value may need a different approach — splitting a calculation, or using a different unit or scale — rather than forcing it into one literal.
3. For generated SQL, validate numeric literal formatting and magnitude before embedding values, and ensure the decimal separator used is always a period, regardless of the runtime locale.
4. Review any calculation producing the value for a bug (overflow or underflow) that might be generating an unexpectedly extreme number in the first place.

Examples

An exponent too large

SELECT * FROM measurements WHERE value = 1e400;
-- -204: the exponent exceeds what can be represented

A locale-mismatched decimal separator

-- Generated by code running under a locale using comma as the
-- decimal separator, without correcting for SQL's expected format:
INSERT INTO readings (value) VALUES (3,14159);
-- -204: read as malformed floating-point punctuation, not "3.14159"

Fix: ensure numeric formatting always uses a period as the decimal separator when building SQL, independent of the runtime locale.

An overflow upstream

-- A calculation bug produces an extreme value (e.g. a division
-- that should have used a safeguard against near-zero denominators)
-- which then gets embedded as a floating-point literal in generated SQL

Fixing the calculation that produced the extreme value addresses the root cause, rather than just handling the resulting -204.

Diagnostic Checks

1. Review the specific floating-point literal's format and exponent magnitude in the failing statement.
2. Check the source of the value — a calculation, a locale-sensitive formatting function — for correctness.

Related Errors / Related Topics

• -203 — "An illegal integer has been found in the statement." The direct integer-value counterpart to this floating-point validation error.
• -201 — "A syntax error has occurred." The general SQL-parsing-error family both belong to.

Check the exponent magnitude and decimal-separator formatting first — those are the two most common actual causes behind this error.