Micro Focus Enterprise Developer 2.3 for Eclipse > Welcome > Product Information > Known Issues and Restrictions > JVM Code > OpenESQL

OpenESQL

JDBC

You cannot directly enable integrated authentication for Microsoft SQL Server in Enterprise Developer. If you use integrated authentication with Microsoft SQL Server, you must add the .jar file for your JDBC driver directly to the Java Build Path or CLASSPATH of your Eclipse project, and then set its native library location.
The following scenario can cause the COBOL compiler to fail to update output host variables when the cursor for a stored procedure call is closed. This can happen when stored procedures meet all three of the following criteria:
- Are called using the OPEN statement
- Return a return value, output parameters, or both
- Return a result set
The failure occurs because the COBOL compiler, when possible, compiles 01-level fields and their subordinate 01-level FILLER fields as JVM types.

To ensure successful compilation, use traditional COBOL data types, such as PIC X(n), COMP-3, etc., for host variables rather than object types, such as string, binary-long, BigDecimal, etc., and do one of the following:
- Compile using the NOILNATIVE COBOL compiler directive
- Declare host variables that receive return values or output parameters at level 02 or higher, with a record name other than FILLER
This scenario does not apply to stored procedures called using the CALL statement.

OpenESQL JVM 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.

Important: If you do not want to take advantage of the performance gains provided by this change in implicit behavior, use the OpenESQL Configuration Utility to change the implicit value of the BEHAVIOR compiler directive back to UNOPTIMIZED. For details, see OpenESQL Embedded SQL Cursor Behavior and Performance.