2 Informix Gateway Features and Restrictions

2.6.2.1 Rules for Naming Objects

Oracle and Informix use different database object naming rules. For example, the maximum number of characters allowed for each object name can be different. Also, the use of single and double quotation marks, case sensitivity, and the use of alphanumeric characters can all be different.

2.6.2.2 Object Names

Names of Informix database objects are limited to a maximum of 18 characters. An object name can be composed of these characters:

• Numbers 0 to 9

• Lowercase letters a to z

• Uppercase letters A to Z

• Underscore character (_)

2.6.2.3 Case Sensitivity

Informix handles letter case differently from Oracle. Informix uses these rules:

• Table owner names default to uppercase letters, unless the name is surrounded by double quote characters

• Column names, table names, view names, and so on, are always treated as lowercase letters

The Oracle database defaults to uppercase unless you surround identifiers with double quote characters. For example, to refer to the Informix table called emp, enter the name with double quote characters, as follows:

SQL> SELECT * FROM "emp"@IFMX;

However, to refer to the Informix table called emp owned by SCOTT from an Oracle application, enter the following:

SQL> SELECT * FROM "Scott"."emp"@IFMX;

If the Informix table called emp is owned by SCOTT, a table owner name in uppercase letters, you can enter the owner name without double quote characters, as follows:

SQL> SELECT * FROM SCOTT."emp"@IFMX;

Or

SQL> SELECT * FROM scott."emp"@IFMX;

Oracle recommends that you surround all Informix object names with double quote characters and use the exact letter case for the object names as they appear in the Informix data dictionary. This convention is not required when referring to the supported Oracle data dictionary tables or views listed in Appendix C, "Data Dictionary".

If existing applications cannot be changed according to these conventions, create views in Oracle to associate Informix names to the correct letter case. For example, to refer to the Informix table emp from an existing Oracle application by using only uppercase names, define the following view:

SQL> CREATE VIEW EMP (EMPNO, ENAME, SAL, HIREDATE)
      AS SELECT "empno", "ename", "sal", "hiredate"
      FROM "emp"@IFMX;

With this view, the application can issue statements such as the following:

SQL> SELECT EMPNO, ENAME FROM EMP;

Using views is a workaround solution that duplicates data dictionary information originating in the Informix data dictionary. You must be prepared to update the Oracle view definitions whenever the data definitions for the corresponding tables are changed in the Informix database.

2.6.3.1 Binary, Byte and Text Literal Notation

Oracle SQL uses hexadecimal digits surrounded by single quotes to express literal values being compared or inserted into columns defined as data type RAW.

This notation is not converted to syntax compatible with Informix BINARY, BYTE and TEXT data types (a 0x followed by hexadecimal digits, surrounded by single quotes).

For example, the following statement is not supported:

SQL> INSERT INTO BYTE_TAB@IFMX VALUES ('Oxff');

Where BYTE_TAB contains a column of data type BINARY, BYTE or TEXT. Use bind variables when inserting into or updating BINARY, BYTE or TEXT data types.

2.6.3.2 Data Type Conversion

Informix does not support implicit date conversions. Such conversions must be explicit.

For example, the gateway issues an error for the following SELECT statement:

SQL> SELECT DATE_COL FROM TEST@IFMX
     WHERE DATE_COL = "1-JAN-2001";

To avoid problems with implicit conversions, add explicit conversions, as in the following:

SQL> SELECT DATE_COL FROM TEST@IFMX
     WHERE DATE_COL = TO_DATE("1-JAN-2001");

2.6.4.1 Row Selection

Informix evaluates a query condition for all selected rows before returning any of the rows. If there is an error in the evaluation process for one or more rows, no rows are returned even though the remaining rows satisfy the condition.

Oracle evaluates the query condition row-by-row and returns a row when the evaluation is successful. Rows are returned until a row fails the evaluation.

2.6.4.2 Empty Strings

Oracle processes an empty string in a SQL statement as a null value. Informix processes an empty string as an empty string.

Comparing to an empty string

The gateway passes literal empty strings to the Informix database without any conversion. If you intended an empty string to represent a null value, Informix does not process the statement that way; it uses the empty string.

You can avoid this problem by using NULL or IS NULL in the SQL statement instead of the empty string syntax, as in the following example:

SELECT * from "emp"@IFMX where "ename" IS NULL;

Selecting an empty string

For VARCHAR columns, the gateway returns an empty string to the Oracle database as NULL value.

For CHAR columns, the gateway returns the full size of the column with each character as empty space (' ').

2.6.4.3 Empty Bind Variables

For VARCHAR bind variables, the gateway passes empty bind variables to the Informix database as a NULL value.

2.7.6.1 WHERE CURRENT OF Clause

UPDATE and DELETE statements with the WHERE CURRENT OF clause are not supported by the gateway because they rely on the Oracle ROWID implementation. To update or delete a specific row through the gateway, a condition style WHERE clause must be used.

2.7.6.2 CONNECT BY Clause

The gateway does not support the CONNECT BY clause in a SELECT statement.

2.7.6.3 Use of NULL Keyword in SELECT Statement

The NULL keyword cannot be used in the select list of a SELECT statement because that syntax is not ANSI SQL.

For example, the following statement cannot be used:

SQL> SELECT NULL FROM . . . 

2.7.6.4 Subqueries in INSERT Statement

Subqueries of INSERT statements cannot use multiple aliases for the same table. For example, the following statement is not supported:

SQL> INSERT INTO "emp_target"@IFMX
         SELECT a."empno" FROM "emp_source"@IFMX a,
            "emp_source"@IFMX b WHERE b."empno"=9999

2.7.6.5 Subqueries in DELETE, INSERT, and UPDATE Statements

SQL statements in subqueries of DELETE, INSERT, and UPDATE statements cannot refer to the same table as specified in the outer query. This is because of the locking mechanism in Informix.

2.7.6.6 ROWID

The Oracle ROWID implementation is not supported.

2.7.6.7 EXPLAIN PLAN Statement

The EXPLAIN PLAN statement is not supported.

2.7.6.8 Callback Support

SQL statements that require the gateway to callback to Oracle database would not be supported.

The following categories of SQL statements will result in a callback:

• Any DML with a sub-select, which refers to a table in Oracle database. For example:

  INSERT INTO emp@non_oracle SELECT * FROM oracle_emp;
  

• Any DELETE, INSERT, UPDATE or "SELECT... FOR UPDATE..." SQL statement containing SQL functions or statements that needs to be executed at the originating Oracle database.

  These SQL functions include USER, USERENV, and SYSDATE, and the SQL statements are in selects of data from the originating Oracle database. For example:

  DELETE FROM emp@non_oracle WHERE hiredate > SYSDATE;
  

  SELECT ename FROM tkhoemp@non_oracle
  WHERE hiredate IN (SELECT hiredate FROM tkhoemp)
  FOR UPDATE OF empno;
  

• Any SQL statement that involves a table in Oracle database, and a LONG or LOB column in a remote table. For example:

  SELECT a.long1, b.empno FROM scott.table@non_oracle a, emp b
  WHERE a.id=b.empno; 
  

  SELECT a.long1, b.dummy FROM table_non@non_oracle a, dual b;
  

where a.long1 is a LONG column.