OpenESQL

ADO.NET

• Be aware that when using ADO.NET with Oracle .NET providers that the original, partially managed, provider and the current, fully managed provider behave differently in some scenarios. If your ADO.NET applications behave differently when switching between these Oracle providers, carefully check that you have the providers configured appropriately.

COBOL Stored Procedures

• If your COBOL stored procedure definition (i.e., your CREATE PROCEDURE statement) contains any INOUT parameters, you must modify every application call to that stored procedure to explicitly declare the direction of all the parameters passed to that stored procedure. For complete information on coding CALL statements, see the CALL topic.
• If your COBOL stored procedure uses a CHAR(n) parameter that is copied to or from a group item (such as an SQLCA structure), then you must declare the parameter as BINARY(n) in the CREATE PROCEDURE statement of your stored procedure, and as SQL TYPE BINARY(n) in the client application.

Compiling

• OpenESQL applications built as managed code with DBMAN=ODBC are only supported when targeting the 4.0 .NET Framework or later. Due to inherent differences between ODBC and managed code, Micro Focus will deprecate DBMAN=ODBC with managed code in a future release.
• The SQL TRACELEVEL directive is no longer supported in applications compiled using DBMAN=ADO.

Dynamic SQL

Dynamic SQL using the SQL Descriptor Area (SQLDA) is not supported in .NET managed code in the following scenarios:

• By OpenESQL applications compiled with the DBMAN=ODBC directive.
• On 64-bit platforms, by OpenESQL applications compiled with the DBMAN=ADO directive, where the Project property Platform Target is set to anything other than x86.

OpenESQL .NET Managed Runtime

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:

• Programs that include the SET SCROLLOPTION or SET CONCURRENCY EXEC SQL statements fail to compile. For affected programs, do one of the following:
  • Before compiling, set the BEHAVIOR compiler directive to UNOPTIMIZED. While this is the simplest solution, we do not recommended it due to the possibility of degraded performance.
  • Remove all SET SCROLLOPTION and SET CONCURRENCY statements and, if necessary, modify the DECLARE CURSOR statement to include appropriate parameters to yield the same behavior. For example, to elicit the same behavior as the SET SCROLLOPTION statement, use the following DECLARE CURSOR statement:

    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.

• The OPTIMIZED setting does not make ambiguous cursors updateable. Therefore, applications that expect cursors to be updateable, according to the default ANSI standards for Embedded SQL, are affected. In this case, we recommend that you set the BEHAVIOR compiler directive option to ANSI.
• The OPTIMIZED setting does not assume scrollable cursors. Therefore, applications that expect cursors to be scrollable are affected. In these cases, we recommend that you modify your DECLARE CURSOR statements to compensate, as specified above.

PostgreSQL Recommendations

• When a negative SQL code is returned to a calling application, PostgreSQL aborts transactions implicitly unless you change the default behavior of the ODBC and/or the ADO.NET driver. To work around this shortcoming, consider modifying the Npgsql ADO.NET driver configuration, setting the PreloadReader property to True.
• PostgreSQL does not accept NULL date, time, or timestamp values from PIC X host variables. You must either use CAST(:hostvar as TIMESTAMP) in the SQL or use SQL TYPE TIMESTAMP in the application.
• PostgreSQL supports embedded NULL characters in binary columns only; it does not support embedded NULL characters in character columns.

SQL CLR Integration

• SQL CLR Integration does not support the use of the - (hyphen) character in parameter names. If you code a hyphen into a parameter name, the following message is returned when attempting to deploy:

  (144,0): error: .Net SqlClient Data Provider: Msg 102, Level 15, State 1, 
  Procedure procName, Line lineNo Incorrect syntax near '-'.