Informix Error -206

Reasons / Common Causes

-206 is one of the most common everyday SQL errors — a table or view referenced in a statement can't be located. The official text also calls out a specific, easy-to-miss variant: a GRANT statement for a user-defined type that's missing the TYPE keyword produces this exact same error, since the parser looks for a table by that name instead of recognizing the intended type-privilege grant.

1. A misspelled table or view name in the statement — the straightforward, most common case.
2. The table or view was renamed since the application or script was written, and the old name is still referenced somewhere.
3. The table or view was dropped — deliberately or accidentally — while something still references it.
4. Connected to the wrong database. The table exists, but in a different database than the one the current session is actually connected to.
5. Owner or schema qualification mismatches — a table created under one owner referenced without the correct qualification.
6. Omitting TYPE when granting USAGE privileges on a user-defined type. GRANT USAGE ON <udt-name> (missing TYPE) triggers -206 because the statement is parsed as referencing a table by that name, not the intended type — this specific variant is easy to miss since the error message looks identical to an ordinary missing-table case.
7. Migration or environment differences — a table that exists in one environment (production) referenced by code or scripts run against a different environment (staging, development) that never had it created.

Solutions / Resolution

1. Verify table and view names directly against the database catalog, per the official guidance:

   SELECT tabname FROM systables WHERE tabname = 'ordrs';  -- check for the exact name/typo
   SELECT tabname FROM systables WHERE tabtype = 'V';       -- list all views
   

2. Confirm you're connected to the correct database — check the current database context before assuming the table is genuinely missing.
3. If a table or view was renamed, update any code or scripts still referencing the old name.
4. If a table or view was dropped, either recreate it or update dependent code to no longer reference it.
5. For the user-defined type variant, include TYPE in the GRANT statement:

   GRANT USAGE ON TYPE my_udt TO some_user;
   

   not

   GRANT USAGE ON my_udt TO some_user;   -- -206: parsed as a missing table, not a type grant
   

6. For environment-specific failures, confirm the table actually exists in the target environment and address any migration or schema-parity gap.
7. Check owner/schema qualification if the table exists but isn't found under the name used in the statement.

Examples

The straightforward typo

SELECT * FROM custmer;
-- -206: intended "customer"

SELECT tabname FROM systables WHERE tabname LIKE 'cust%';
-- confirms the actual table name

The missing TYPE keyword

GRANT USAGE ON money_udt TO app_user;
-- -206: "money_udt is not in the database" — but money_udt is a
-- user-defined type, not a table; TYPE was omitted

Fix:

GRANT USAGE ON TYPE money_udt TO app_user;

Wrong database connected

DATABASE staging_db;
SELECT * FROM orders;
-- -206: orders exists in prod_db, not staging_db

DATABASE prod_db;
SELECT * FROM orders;
-- succeeds

Diagnostic Checks

1. Query systables/sysviews to confirm the object exists and get its exact name:

   SELECT tabname FROM systables WHERE tabname LIKE '%partial_name%';
   

2. Confirm the current database connection.
3. If the object in question is a user-defined type, review the exact GRANT statement for a missing TYPE keyword.
4. Check schema/owner qualification if the table genuinely exists but isn't being found.

Related Errors / Related Topics

• -201 — "A syntax error has occurred." The general SQL-parsing-error family this fits into.
• -130 — "ISAM error: no such dbspace." A different layer's "no such X" condition — worth knowing about together as the same general troubleshooting pattern (verify the exact name against the catalog) applied to storage objects instead of tables.

If the object in question is a user-defined type, check for a missing TYPE keyword in the GRANT statement before assuming the table itself is genuinely missing — this is the specific, non-obvious variant the official guidance calls out.