JDBC Type 4 Driver Programmer's Reference for SQL/MX Release 3.1 (H06.23+, J06.12+)

A run-time version of a table has a different redefinition timestamp than the compile-time version of the same table.
An existing open operation on a table was eliminated by a DDL or SQL utility operation.
The transaction isolation level and access mode at execution time is different from that at the compile time.
For more information on SQL/MX recompilation, see the SQL/MX Programming Manual for C and COBOL or the SQL/MX Programming
Manual for Java.
When a query is recompiled, the SQL/MX executor stores the recompiled query; therefore, the query is recompiled only once until any of the
previous conditions are met again.
The Type 4 driver pools CallableStatement objects in the same way as PreparedStatement objects when the statement pooling is activated.
The Type 4 driver does not cache Statement objects.
Thread-safe SQL/MX Access
In the Type 4 driver, API layer classes are implemented as instance-specific objects to ensure thread safety:
SQLMXDataSource.getConnection() is implemented as a synchronized method to ensure thread safety in getting a connection.
Once a connection is made, the connection object is instance-specific.
If multiple statements are run on different threads in a single connection, statement objects are serialized to prevent data corruption.
"Update ... Where Current of" Operations
The fetch size on a ResultSet must be 1 when performing an update ... where current of cursor SQL statement.
If the value of the fetch size is greater than 1, the result of the
update ... where current of operation might be one of the following:
An incorrect row might be updated based on the actual cursor position.
An SQLException might occur because the cursor being updated might have already been closed.
Note: By default, the fetch size is 1.
The following is an example of setting a result set's fetch size to 1 and executing an update ... where current of cursor SQL statement.
ResultSet rs;
...
rs.setFetchSize(1);
String st1 = rs.getCursorName();
Statement stmt2 = connection.createStatement( ResultSet.TYPE_FORWARD_ONLY
, ResultSet.CONCUR_UPDATABLE );
stmt2.executeUpdate("UPDATE cat2.sch2.table1
set j = 'update row' WHERE CURRENT OF " + st1);
Internationalization (I18N) Support
When String Literals Are Used in Applications
Controlling String Literal Conversion by Using the Character-Set Properties
Trimming Padding for Fixed-Length Character Columns
Localizing Error Messages and Status Messages
When String Literals Are Used in Applications
Internationalization support in the driver affects the handling of string literals. The Type 4 driver handles string literals in two situations.
When the driver processes an SQL statement. For example,
Statement stmt = conection.getStatement();
stmt.execute(“select * from table1 where col1 = ‘abcd’”);
When the driver processes JDBC parameters. For example,
PreparedStatement pStmt = connection.prepareStatement(“select * from table1 where col1 = ?”);
pStmt.setString(1, “abcd”);
To convert a string literal from the Java character set to an array of bytes for processing by the SQL/MX engine, the Type 4 driver uses the
column type and character set in the database. For information about column data types and character sets, see the
SQL/MX Reference
Manual.
Controlling String Literal Conversion by Using the Character-Set Properties
The Type 4 driver provides character-set mapping properties. These properties allow you to explicitly define the translation of internal SQL/MX
database character-set formats to and from the Java string Unicode (UnicodeBigUnmarked) encoding.