Known Ingres Issues to Resolve
There is a change in behavior that could affect your application depending on the versions of Ingres being used. In very rare situations, in order to introduce new functionality, Ingres has had to introduce a slight change in behavior that could affect your application.
Ingres Result Type Differences
ISSUE: In Ingres 9.2.0 or higher, the return value of the CHAREXTRACT() function was changed from a nullable char(1) to a nullable varchar(4) to support multi-byte languages and the UTF-8 character set. Since OpenROAD 6.0 now shares some common code with Ingres 9.2, this could cause some unexpected side effects.
For example, in the following code fragment, you could get different results between previous versions of OpenROAD and OpenROAD 6.0:
av = varchar(10) not null;
av = 'a' + Pad(charextract('abc', 2)) + 'c';
In previous versions of OpenROAD, av contained 'abc' with a length equal to three. In OpenROAD 6.0, av contains 'ab c' with a length equal to six.
If you have a local installation of OpenROAD 6.0 with Ingres 9.2.0 or later, and this version of OpenROAD also runs against a remote Ingres Server 9.0.4 or earlier, you will see differences in return types from the two Ingres versions.
RESOLUTION: If your application handles only single-byte characters, you can use BYTEEXTRACT() to replace CHAREXTRACT() to resolve the issue; otherwise, you must fix your application.
Building C Code Containing EXEC SQL Commands
ISSUE: Problems result when you build *.c files from *.sc files that contain EXEC SQL (ESQL/C) commands using esqlc. If you use esqlc, it could produce C code incompatible with OpenROAD. This is why esqlcor is shipped with OpenROAD 5.0 and later.
RESOLUTION: Use esqlcor to build your *.c files instead of esqlc to pre-process ESQL/C applications.
For more information and instructions to use esqlcor in building C files, see the Readme_4GLsample.txt file in $II_SYSTEM/ingres/w4glsamp/esqlc.