Informix Error -202

Reasons / Common Causes

-202 means a character that can't be interpreted as part of SQL is embedded in the statement. This is usually invisible at a glance — the official text specifically points at nonprinting control characters as the likely culprit when a program constructed the statement.

1. A non-printable control character embedded in a programmatically-constructed statement — common when a control character from a file read, a network transfer, or a string- concatenation bug ends up embedded without anyone noticing, since it doesn't display visibly.
2. Copy-pasting SQL from a source with hidden formatting — word processors, PDFs, or rich-text sources can insert invisible characters (smart quotes, non-breaking spaces, other Unicode characters) that aren't valid printable ASCII.
3. Character encoding mismatches — a statement generated in one character encoding but interpreted by the connection or driver in a different one, producing garbled or invalid bytes.
4. String concatenation bugs in application code — a stray byte from an off-by-one substring operation, an accidentally included null terminator, or malformed multi-byte character handling.
5. Data read from a file or external source containing embedded artifacts (a byte-order mark, a bare carriage return, or similar) used directly to build a SQL string without sanitization.

Solutions / Resolution

1. Ensure the statement contains only printable ASCII characters, per the official guidance, and re-execute it.
2. Add validation or sanitization for programmatically-generated statements to strip or reject non-printable control characters before sending them to the database.
3. Avoid copy-pasting SQL from rich-text sources. If unavoidable, paste into a plain-text editor first to strip hidden formatting characters, then copy from there into the actual SQL tool.
4. Check character encoding consistency along the whole path — file, application, driver, connection — if this appears with data pulled from external sources or files.
5. Review string-building code for bugs that might introduce stray bytes, especially around substring operations, escaping, or multi-byte character handling.
6. Use a tool that displays non-printable characters explicitly (a hex dump, or an editor with "show invisible characters" enabled) to pinpoint exactly which character is the problem when troubleshooting a specific statement.

Examples

Smart quotes from a copy-paste

SELECT * FROM customer WHERE name = 'Jane Doe';
-- looks correct at a glance, but pasted from a word processor —
-- the quote characters are actually Unicode "smart quotes"
-- (' '), not ASCII apostrophes, and read as illegal characters

Retyping the quotes directly (or pasting through a plain-text intermediary) resolves this.

A byte-order mark from file-sourced data

-- A SQL statement built by reading a file that begins with a
-- UTF-8 byte-order mark (BOM) embeds that BOM at the start of
-- the generated statement, invisible in most text editors

Stripping the BOM before using file contents to build SQL avoids this class of failure.

Diagnostic Checks

1. Hex-dump or otherwise inspect the exact bytes of the failing statement to identify the specific illegal character.
2. Check the source of the statement — hand-typed, copy-pasted, programmatically built, or file-sourced — to narrow down where the character was likely introduced.
3. Check character encoding settings along the full path from source to database connection.

Related Errors / Related Topics

• -201 — "A syntax error has occurred." The closest sibling in the general SQL-parsing error family.
• -200 — "Identifier is too long." Another general SQL parser-level error in the same immediate numeric neighborhood.

Use a tool that reveals non-printable characters explicitly — this is almost always faster than staring at the statement itself, since the actual problem character usually isn't visible in a normal text view.