To compile OpenESQL applications that use a 64-bit Data Source Name (DSN) for 32-bit platforms, and for which you specify the CHECK or DB compiler directive options, you must explicitly create a 32-bit DSN of the same name as the 64-bit DSN. Do this using either the ODBC Data Source Administrator (32-bit) or the ADO.NET Connection Editor. The execution process continues to use the 64-bit DSN.
If you use CHARSET(EBCDIC) when compiling COBOL code that contains SQL host variables that are of the display numeric type defined as XXXXXX, you must link to the oesqlebc library to prevent link errors.
You can either set up the link from the IDE and recompile, or run the required commands from a command prompt after compiling.
From the IDE, before compiling or recompiling:
From a command prompt, after compiling:
set lib=installDir\lib;%lib% cbllink myapp.obj oesqlebc.libWhere installDir is the path to your Visual COBOL installation (by default, this is %ProgramFiles(x86)%\Micro Focus\Enterprise Developer, and myapp is the name of your COBOL object file.
Any EXEC SQL statement that specifies a table or column name containing one or more special characters must have that table or column name enclosed in quotes to prevent a preprocessor error. A special character is an ASCII character with a value greater than 128 or a hexadecimal character with a value greater than x"80".
When using Oracle's ODBC driver, array fetches and some scrolling fetches might produce inconsistent behavior if you change the array size between fetches. To overcome this, build your application with SQL(NORESULTARRAY). When this is set, OpenESQL performs single row fetches under the covers, bypassing this limitation.
OpenESQL applications are optimized for performance by default, with OpenESQL now implicitly setting the BEHAVIOR compiler directive to OPTIMIZED; with previous products, the BEHAVIOR compiler directive was implicitly set to UNOPTIMIZED. This change can impact program behavior as follows:
EXEC SQL DECLARE cursorname SCROLL LOCK CURSOR FOR…
By default, cursors are forward and read only. If this is the desired behavior, you can safely remove the SET statements with no further action required. However, we recommend as a matter of good practice to always include FOR READ ONLY or FOR UPDATE in cursor declarations to ensure that the default behavior is always explicit. We recommended this solution.
To work around these shortcomings, consider modifying the psqlODBC driver Configuration Options. To do this: