Informix Error -556: Cannot create, drop, or modify an object that is external to current database.
Cause and resolution
Cannot create, drop, or modify an object that is external to current database.
This statement attempts to create, drop, or alter an object in an external database, one other than the current database. You can only read the contents of an external database.
If you make the external database your current database, you can modify the contents. Review all uses of names beginning with <dbname>, which refers to an object in the external database <dbname>. </dbname></dbname>
The local database (the coordinator) can reference the objects on a remote database (a participant), but a remote database cannot reference objects on the local database or on any other database. You can query data from a remote database, but you cannot perform DDL operations on a remote database. and You cannot execute a remote routine which queries data from a remote table.
Example 1: You cannot performs DDL operations in a remote database, whether that database is on the same server or a remote server
The following procedure is created on the server Server_B in database named as 'db':
CREATE PROCEDURE test_qry() create table tab(col1 int); END FUNCTION;
The following statement run on the server Server_A fails because the procedure was created on the server Server_B:
EXECUTE PROCEDURE db@server_B:test_qry();
The following statement run on the server Server_A from in the database 'db1' fails because the procedure was created in the database 'db':
EXECUTE PROCEDURE db:test_qry();
Or
The following SQL statement fails to create a table 'tab1' on remote server Server_B in database 'db1'.
CREATE TABLE db1@Server_B:tab(col1 int);
Example 2 : You can read data from a remote table, whether the table is created across different database in a same server instance or at remote server.
The following function is created in database named 'db1' on 'Server_B' and selects rows from a remote table in the database named 'db':
CREATE FUNCTION test_qry_1() returning integer; RETURN (SELECT iid FROM db:onerow); END FUNCTION;
The following statement run in the database 'db' succeeds: EXECUTE FUNCTION db1:test_qry_1();
or
The following SQL statament successfully run on server 'Server_A' that queries data from a remote table located at 'Server_B' SELECT * from db1@Server_B:tab1;
Example 3 : You cannot query local data using a remote routine.
The following function is created on server Server_B and queries data on the server Server_A:
CREATE FUNCTION test_qry() returning integer; RETURN (SELECT iid FROM db@server_A:onerow); END FUNCTION;
The following statement run on the server Server_A fails, even though it queries data on Server_A, because the function test_qry was created on Server_B:
EXECUTE FUNCTION db@Server_B:test_qry();
Oninit® Troubleshooting Guidance
Reasons / Common Causes
-556 fires when a DDL statement (CREATE/DROP/ALTER and similar) or another data-modifying
operation targets an object qualified with an external database name (<dbname>:object or
<dbname>@servername:object) — cross-database access is read-only from outside that database.
- DDL issued against an object qualified with a different database's name, per the official guidance — the direct, only cause.
- A misunderstanding of cross-database access scope: per the official guidance, an external database's contents can be read from the current database, but not created, dropped, or modified without making that database the current one.
- Remote-routine execution combined with a data query against a remote table, per the official guidance's further note — this combination is also prohibited even though each piece alone might be allowed.
Solutions / Resolution
- Make the external database the current database first, per the official guidance, if the
object genuinely needs to be created, dropped, or modified:
DATABASE other_db; DROP TABLE staging_import; - Review all uses of
<dbname>-qualified names in the statement, per the official guidance, to confirm which ones are genuinely meant to be external (read-only) versus which one should actually be the current database. - Split combined remote-routine-plus-remote-data-query operations into separate steps, per the official guidance's note on that specific restriction.
Examples
The disallowed attempt
DROP TABLE other_db:staging_import;
-- -556: other_db is external to the current database
Corrected — switch databases first
DATABASE other_db;
DROP TABLE staging_import;
Diagnostic Checks
- Scan the statement for any
<dbname>:or<dbname>@servername:-qualified object name in a DDL or modifying context, and confirm whether that database should actually be the current one instead.
Related Errors / Related Topics
- -557 — "Cannot locate table that is external to the current database after
levels of synonym mapping." A related cross-database error, about an unresolvable synonym chain rather than a write attempted against a read-only external object.
External databases are read-only from outside — switch to the target database first if a write is genuinely needed there.