Change History

The following sections document changes in the drivers.

New Functions

This section describes the main new functions of each Mimer JDBC version.

New Functions in 3.42.2

Sealed library

The JDBC library is now sealed. This will prevent code outside the mimjdbc library to access package access components inside the mimjdbc library. It is unlikely such (unsupported) practice occurred, but if it does, it is now likely to fail.

Maven distribution

The JDBC driver is now also distributed via Maven. The library manifest now contains implementation information such as vendor, library version, build date etc in order with Maven requirements.

Direct JAR command line invocation

It is now possible to run the command line diagnostic tools directly from the command line without specifying main class. For example:

java -jar mimjdbc3.jar --version

New Functions in 3.42

LOAD statements

Support for START LOAD, COMMIT LOAD and ROLLBACK LOAD has been added. Executing these statements with an older JDBC driver will return the error -22053 "Statement type not recognized", when any of these statements is attempted.

New Functions in 3.41

Encrypted Network Communication

128-bit AES-GCM encryption may now be used for network communication between the server and the clients.

For further information, check the Mimer SQL System Management Handbook, the section on Network Encryption under the chapter Managing a Database Server.

New Functions in 3.39

Support for the BUILTIN.UUID server data type

Support for the type BUILTIN.UUID is added in the form of being able to set the UUID using PreparedStatement.setObject, PreparedStatement.setString, PreparedStatement.setBytes and PreparedStatement.setBinaryStream.

Conversely, result set columns (or output parameters) may be accessed using ResultSet.getObject, ResultSet.getString, ResultSet.getBytes or ResultSet.getBinaryStream.

New Functions in 3.38

Connection authentication using the Secure Remote Password protocol

Connection authentication using the Secure Remote Password protocol is now used whenever available on the server. This authentication method is available only on Mimer version 11 servers and later.

New Functions in 3.35

Connection.isValid

The JDBC 4 feature Connection.isValid is now implemented and supported. The function confirms the validity of the connection by issuing a server request. If there is a communication error or the response is not received within the specified timeout period, the connection is deemed invalid and false is returned.

New Functions in 3.31

Running JDBC Applications in SINGLE Mode

From version 3.31 it is now possible to run JDBC in SINGLE mode. To run SINGLE the mimcomm shared library is required and is used when the protocol "single" is being used.

VMS:On OpenVMS, mimcomm libraries older than version 10.1 will not work.

New Functions in 3.30

Support for SQL statements START TRANSACTION, COMMIT and ROLLBACK

The JDBC driver now interprets the SQL statements START TRANSACTION, COMMIT and ROLLBACK properly. Previously, the driver threw an exception referring to the transaction control methods available through the java.sql.Connection class.

If a START TRANSACTION statement is executed, a transaction is explicitly started. If auto commit is on, the auto commit mode is temporarily turned off until the transaction is committed. If a transaction is already running, the START TRANSACTION statement is ignored.

If a COMMIT statement is executed the transaction is committed, very much like calling java.sql.Connection.commit.

New Functions in 3.28

Error Position and Length Returned in SQLException and SQLWarning Objects

If an error is related to a specific part of the supplied SQL code, such as a grammatical error, the character position if such an error is now available through a call to the Mimer specific method getErrorPosition(). The length of the error is available through a call to the method getErrorLength(). To call these methods, the application need either to cast the SQLException to a com.mimer.jdbc.SQLException object, or use the reflection API to get hold of the method in question.

For example, the following code example would allow the application to retrieve the character position within the SQL code concerned with the error:

} catch (java.sql.SQLException se) {

  try {

    java.lang.reflect.Method method =

      se.getClass().getMethod("getErrorLength",new Class[0]);

    output.println("-- errorlength = "+method.invoke(se,new Object[0]));

  } catch (NoSuchMethodException nsme) {

    output.println("-- errorlength = unknown");

  }

}

Support For Very Many Columns

Previous versions of this JDBC driver did not support SQL queries with more than 1017 columns. The application would experience an "output descriptor overflow" error (-19053) when calling Statement.execute, Statement.executeQuery, Connection.prepareStatement or Connection.prepareCall. This limit has now been removed.

New Connection Properties

Two new connection properties are introduced for entering a program ident during connect. The properties are program and programPwd, where program is program ident name, and programPwd is the password for the program ident.

setString on BOOLEAN

setString on BOOLEAN parameters now accepts the strings "1" and "0" in addition to "true" and "false".

New Functions in 3.26

User-Defined Types

The driver now offers full support for user-defined types. User-defined types may be fetched into generalized java.sql.Struct objects as well as custom made Java objects which interacts with the driver using the java.sql.SQLData, java.sql.SQLInput and java.sql.SQLOutput interfaces. The driver also provides the type mapping feature needed to map SQL types to the created custom Java classes.

The metadata views needed to inspect existing types and their attributes (DatabaseMetaData.getUDTs and DatabaseMetaData.getAttributes) are also now provided.

See User-Defined Types for information and examples.

New Functions in 3.25

Full Support for Mimer 10.1 Server Unicode identifiers

The JDBC driver offers full support for the full Unicode identifiers that will be introduced with the Mimer SQL version 10.1 servers.

New Functions in 3.24 and 2.24

Support For .setNetworkProtocol And .getNetworkProtocol

The setter and getter routines javax.sql.DataSource.setNetworkProtocol and javax.sql.DataSource.getNetworkProtocol has been added to allow applications to alter protocol type. These routines are synonyms to the already existing .setProtocol and .getProtocol.

New Functions in 3.18, 2.18 and 1.18

The JDBC version 18 drivers may now connect to Mimer SQL Micro servers. Note however, that many features you normally expect in a Mimer SQL Engine are not available in the Mimer SQL Micro Edition server.

An application may detect the Mimer SQL product type by calling DatabaseMetaData.getDatabaseProductName(). This will return “Mimer SQL Micro”, “Mimer SQL Mobile”, or ”Mimer SQL Engine” - depending on the server type.

New Functions in 3.17, 2.17 and 1.17

Support for the BOOLEAN SQL data type that was introduced in Mimer SQL 9.3 servers.

New Functions in 3.16, 2.16 and 1.16

The driver can load and use the mimcomm JNI library which allows the JDBC driver to use all communication methods supported by Mimer on the platform.

The classes MimerDataSource, MimerConnectionPoolDataSource and MimerXADataSource have two additional properties: protocol and service. These are needed when using the mimcomm JNI library. The new properties are explained further in Deploying Mimer JDBC in JNDI.

New Functions in 3.15

The first release of a JDBC 3 compliant driver.

Holdable cursors.

New Functions in 2.9

Server data type NATIONAL CHARACTER LARGE OBJECT (NCLOB) is now supported.

New Functions in 2.8

The method PreparedStatement.setBytes is now supported on LONGVARBINARY and PreparedStatement.setString on LONGVARCHAR. In the case of Mimer, LONGVARBINARY is the same as a BLOB, and LONGVARCHAR is the same as a CLOB.

New Functions in 2.7

The object returned when calling .getBinaryStream, .getAsciiStream and .getCharacterStream on BLOB and CLOB objects now implements the .mark(), .reset() and .skip() methods.

New Functions in 2.5

Support for large objects; BINARY LARGE OBJECT (BLOB) and CHARACTER LARGE OBJECT (CLOB). BLOB’s store any sequence of bytes, CLOB’s store Latin-1 character data.

New Functions in 2.4

Support for server NCHAR and NCHAR VARYING data types. They are used to store Unicode data. By using these data types, any Java String object can now be stored in the database. This is not the case when using CHARACTER or CHARACTER VARYING data types since these can only store Latin-1 characters.

New Functions in 2.3

Support for javax.sql.DataSource.

Support for connection pooling using javax.sql.ConnectionPool DataSource

Support for distributed transactions (XA).

New Functions in 2.0

Scrollable cursors are now fully supported.

All date, time and timestamp methods now support the java.util.Calendar class for handling time zones. Mimer SQL 8.2 servers do not currently support time zones and this feature enables you to use time zones.

Batches of statements are supported.

Batches of prepared statements are supported. Batches of prepared statements are really useful for increasing performance when executing several INSERT, UPDATE or DELETE statements.

Batches of callable statements are supported.

There are now setter and getter methods for CharacterStreams.

Several new DatabaseMetaData methods.

Support for the Mimer SQL statements ENTER and LEAVE.

New Functions in 1.9

Server data type NATIONAL CHARACTER LARGE OBJECT (NCLOB) is now supported.

New Functions in 1.7

When working with a Mimer SQL version 9 server, the JDBC 1 driver now supports the new version 9 data types (NCHAR, NCHAR VARYING, BINARY LARGE OBJECTS, and CHARACTER LARGE OBJECT).

The SQL statements ENTER and LEAVE are now supported.

New Functions in 1.2

Support for query timeout and cancel. (Connection timeout is not supported.)

Changed Functions

This section describes the main changed functions of each Mimer JDBC version.

Changes in 11.0.1

Version numbering scheme changed

The version number scheme changed to having the major and minor version being equal to the matching server version, for example 11.0 and 11.1. The subrelease is the order number of the JDBC driver. For example 11.0.1, 11.0.2 etc.

The first JDBC version released with the new version number scheme is 11.0.1. The previous version was 3.42.3.

Changes in 3.41

Trailing blanks are now ignored during connect

The JDBC driver now ignores trailing blanks in ident names and passwords during connects. For example, this means connecting to the ident "NOBLANKS" using the name "NOBLANKS " will succeed. Previously, this failed with a Login failure.

Changes in 3.40

Reduced memory consumption

Substantial work has been undertaken to reduce the amount of memory allocated by the driver, specifically during common operations such as preparing and executing statements, creating results sets, and working with common data types.

Changes in 3.39

Corrected behavior of ResultSet.isBeforeFirst for empty result sets

The previous behavior of ResultSet.isBeforeFirst was to always return true when at the beginning of the result set, no matter if it contained any rows or not. This has been incorrect and not compatible with the JDBC specification which mandates that false should be returned for empty result sets.

The behavior is now changed to make the routine return false for empty result sets.

Corrected behavior of current row number on scrollable empty result sets

Previously ResultSet.getRow() returned 1 on empty result sets if ResultSet.next(), or any other cursor positioning call was made. This was incorrect. Now, the cursor position is always 0 on empty result sets.

Corrected behavior of current row number when at the end of the result set

Previously ResultSet.getRow() returned the number of rows in the result set plus one if the cursor was at the end. This was incorrect. If the cursor is not on a row, 0 should be returned. This is now corrected.

Statement.setEscapeProcessing is ignored by version 11 servers

The escape clauses are from version 11 servers onward part of the SQL compiler grammar and always considered. The method java.sql.Statement.setEscapeProcessing to enable or disable escape clause processing, is therefore ignored when connected to those servers.

JDBC now requires 9.2 servers or later

Previously JDBC clients has supported version 8.2 servers (or later.) Now, version 9.2 is required.

Changes in 3.29

Specific Login Failure Error Code

When both the program and programPwd connection properties are supplied, and the connection attempt fails, a specific error code is now returned to catch these errors. From this version, an SQLException with the native error code  -2110, message  "Program login failure" is thrown.

Changes in 3.28

Object Finalizers Now Never Make Server Calls

Object finalizers, such as the finalizers for Connection, ResultSet, and Statement-objects, used to make server calls to close the corresponding server objects. They now never do that, but rather note that the object should be freed on the server side, and the actually close call to the server takes place at later point in time. This is because finalizers are called by garbage collector and on some platforms the garbage collector is sensitive to things that might take a long time, such as a remote network request.

Programmers are advice to explicitly close their database objects at any times to make the server release unused resources as soon as possible.

Changes in 3.25

When using the protocol local to connect to the database server the shared library mimcomm.dll is used. When using 64-bit Java the system has been changed to use the mimcomm64.dll. This library is present in 64-bit installations of Mimer SQL from version 10.0.6.

Changes in 3.24, 2.24 and 1.24

Strict Sort Order in DatabaseMetaData.getTypeInfo

The sort order in which rows are returned when calling DatabaseMetaData.getTypeInfo is now more strict. Previously, rows were only sorted on DATA_TYPE (the integer type code). Now, the rows are sorted on DATA_TYPE, core data types first then domains, and TYPE_NAME.

Changes in 3.20, 2.20 and 1.20

Improved absolute positioning on scrollable result sets

Previously the driver made two server calls when positioning relative to the end of result set when the result set size was not known. This includes positioning to the last record. Now, the driver will under all circumstances make at most one server call to position the cursor.

Changes in 3.16, 2.16 and 1.16

Changed type mapping for FLOAT(n)

Mimer SQL supports the data type FLOAT(n) which can store a floating point number with n digits of mantissa and an exponent ranging from -999 to 999.

This data type was previously mapped to the Java type double (which only supports exponents ranging from -308 to 308). This was problematic since some routines (in particular getObject()) would fail for very large (or small) values in the database.

The FLOAT(n) data type is now mapped to java.math.BigDecimal. While not a perfect match, this data type can accurately represent all values that can be stored in FLOAT(n) columns in the database.

Note that it is still possible to use the methods getDouble() and getFloat() on FLOAT(n) data, but those methods will fail when the data is out of range for a Java double (or float).

To store Java double and float values, consider using the Mimer data type DOUBLE PRECISION for Java double and the Mimer data type REAL for Java float.

Note that the Mimer data type FLOAT (without a precision) is synonymous to DOUBLE PRECISION and is a bad match for the Java float type which is single precision.

Changed string representation for floating point data

The JDBC driver supports the getString() method on all Mimer floating point columns. Previously this method padded the returned value with zeros to its declared precision (a FLOAT(15) could return “1.00000000000000”). This version will not add those zeros (getString() on the same value will return “1”).

Changes in 2.15 and 1.15

Login failure now returns SQLSTATE 08004.

Previously login failure threw an SQLException with the SQLState 28000. According to the SQL-2003 standard, this is incorrect, and has been corrected to return 08004. The 08-class of SQLStates relates to error conditions during the connect phase.

Several error messages have been clarified

Error texts returned when a cast from a character column to something else now more clearly state the failed cast. Note that this particular improvement applies to client side casts only. For instance, this includes casts where an SQL parameter type is INTEGER and its value is set using the PreparedStatement.setString method.

The driver now displays an accurate error text when a connection attempt fails because the application hasn't specified the database name, or it has specified an empty database name.

When the application refers to a column name that does not exist in the result set, the error text now includes existing columns names. To keep error texts reasonably short, if this error occurs on a result set with many columns, only a selection of column names. This situation is indicated with three consecutive periods in the error text.

Errors returned from the Mimer TCP server (listening on port 1360 on behalf of Mimer SQL servers) now include a descriptive text, previously only the error code was displayed to the caller.

Changes in 2.14 and 1.14

Extended Server Information

JDBC clients now present more detailed information to the servers about who it is, which version it is and in which environment it is executing in. Future servers will provide tools to monitor this information.

Changing autocommit mode always commits open transactions

Earlier on, the Mimer JDBC driver mimiced the ODBC behavior when autocommit mode is changed. The ODBC spec says that open transactions should be automatically committed when the autocommit mode goes from off to on. The JDBC specification requires drivers to commit open transactions on all changes in autocommit state. From version 14 onwards, the Mimer JDBC driver implements this behavior.

An observant reader might question why this has any significance at all? After all, when autocommit mode is on, we expect all statements to be committed automatically anyway? The difference lies in how open result sets are treated. As you may know, result sets are by default closed when transactions are committed. In practice, running in autocommit mode means that transactions are committed _as_soon_as_possible_. For instance, a statement returning a result set will typically be committed when the application explicitly closes the result set, or if the result set is forward-only when the entire set has been read. Changing the autocommit mode during the life of the result set will now always trigger a commit which will close the result set.

Changes in 2.9

The driver now returns the correct object type when doing CallableStatement.getObject. According to the JDBC specification, getObject should return a Java object whose type corresponds to what type the output parameter was registered to with the CallableStatement.registerOutParameter method call. Earlier drivers always returned the default Java object type.

Changes in 2.7

All .getUnicodeStream on NCHAR columns no longer throw IndexOutOfBoundsException.

All .getCharacterStream returned incorrect results for NCHAR and NCHAR VARYING columns. This problem is corrected.

All .getAsciiStream, .getBinaryStream, and .getCharacterStream on CHAR, CHAR VARYING, NCHAR, NCHAR VARYING, BINARY and BINARY VARYING columns have been reworked to reduce memory footprint, and also to provide more efficient .mark(), .reset(), and .skip() implementations.

Changes in 2.2

Column names and labels are now regarded as equal. From an SQL standard point of view, the column name should be hidden when a correlation name is specified.

Both ResultSetMetaData.getColumnName and ResultSetMetaData.getColumnLabel return the correlation name when one is specified.

Default network buffers have been reduced in size to increase server scalability.

Changes in 2.1

A Mimer SQL beta license key is no longer required on the server.

Changes in 1.3

Statement.executeQuery no longer accepts non-query statements and Statement.executeUpdate no longer accepts statements other than updates, inserts or deletes.

Changes in 1.2

The name of the Mimer driver class is changed to com.mimer.jdbc.Driver (earlier com.mimer.jdbc1.Driver).

Corrected Problems

This section describes the main corrected functions of each Mimer JDBC version.

Corrections in 11.0.1

When using multiple class loaders, driver may throw UnsatisfiedLinkError

When the application is loading the Mimer JDBC driver and connecting through multiple custom class loaders, the driver throws ‘UnsatisfiedLinkError: Native library <x> already loaded in another classloader’, when connecting to the database server using the local, nativetcp or single protocol.

The correction involves making a temporary copy of the shared library providing native access to the database. The temporary copy is placed in a directory with restricted access privileges in the temporary directory as specified by the java.io.tmpdir system property. The default value of this property varies depending on platform but is normally /tmp on Linux, the directory referenced by the TEMP environment variable on Windows and the directory referenced by the SYS$SCRATCH logical name on VMS.

Corrections in 3.42

ResultSet.getDate, .getTime and .getTimestamp used the incorrect timezone when java.util.Calendar was specified

Previous versions of the JDBC driver used the incorrect timezone when a java.util.Calendar was supplied when setting an SQL DATE, TIME or TIMESTAMP (which does not have a time zone) parameter value using a java.sql.Date, java.sql.Time or java.sql.Timestamp object. The correct behavior is that the Calendar object contains a timezone which specifies the timezone to be used for the stored value while the time in the java object contains the timezone which is was created in (nearly always the current time zone of the Java runtime). Essentially, the Calendar object should in most cases specify the timezone of the database server. This means that if the Java runtime runs in the GMT+4 timezone, setting the time 12:00:00 using a Calendar object specified to be in timezone GMT+1 the time used in the parameter value should be 09:00:00.

The previous, incorrect, behavior was that the timezone of the Calendar object was used to determine the timezone of the value to be set, and where the actual data in the database was assumed to be GMT+0. This meant, in the above example, that when the time 12:00:00 was to be set with the Calendar with timezone GMT+1, the value used in the parameter was 11:00:00.

Register pair 1/2 contains wrong type.

When calling the java.sql.SQLInput.readDouble or java.sql.SQLInput.readLong methods when accessing User Defined Types in version 10.1 servers, the following errors was triggered in JDBC version 3.41.a. The problem does not appear when working with version 11 servers. There is no known workaround, other than using other methods.

readLong signature: ()J) Register pair 1/2 contains wrong type

readDouble signature: ()D) Register pair 1/2 contains wrong type

Corrections in 3.41a

Incomplete Scrollable Result set

Scrollable result sets created with a statement using at least one parameter, when connected to a server of version 10.1 or older, were erroneously detecting end of table at a certain point in the result set, causing the end of the result set to not being returned. The point where the end was detected was when about 64 kb had been returned. Smaller result sets were unaffected by the error.

Corrections in 3.40

Invalid internal statement identifier after Statement.getResultSet

Corrected issue introduced in version 3.39 where the error -19039 "Invalid internal statement identifier" occurs if execute is made using Statement.execute, the statement was a query and the ResultSet object was picked up using Statement.getResultSet. There must also be an already existing statement executing before this execute, and that there are fetches on that result set prior to the call to ResultSet.next which triggers the error. The result set must also have a certain size, large enough so that it does not fit in the first response from the server. This size is by default 60 kb, but may vary depending on fetch size.

NullPointerException after Statement or ResultSet object has been finalized prior to being returned to connection pool

When Statement or ResultSet objects has not been explicitly closed by the application, they are eventually garbage collected by the JVM. If this occurred just before the connection was returned to the connection pool, a NullPointerException occurred. This problem was introduced in JDBC 3.26.

Truncation of TIME and TIMESTAMP decimals produced an exception, rather than a warning.

When TIME and TIMESTAMP decimals was truncated when setting a parameter, an exception was previously thrown with the error code -22061 and text "Datetime field overflow". This has now been changed to a warning (accessible by calling PreparedStatement.getWarnings). An example situation were this will occur is when a TIMESTAMP(2) is set with the value '2019-11-10 12:13:14.156'.

Corrections in 3.39

NullPointerException calling ResultSet.isLast

Connecting to older servers could in version 3.38 give an internal -19078 error. The error appears if the ident name supplied during login was 3+4n characters long (for any n>=0).

-19078 errors when connecting to older servers

The releases 38.a and 38.b contained an error causing ResultSet.isLast to throw a NullPointerException if they were called on a forward only result set which had reached the end, or in other words was position at after last row.

When connecting to 10.1 servers and older an -19041 internal error could appear

Unusual errors during the connect phase would trigger an auxiliary error -19041 with the following text "Error -19041 while retrieving error description for ...". The situation occurred when the server returned an error which wasn't already known by the JDBC client, which in itself in rather unusual.

ResultSet.isLast problem

The releases 38.a and 38.b contained an error causing ResultSet.isLast to throw a NullPointerException if they were called on a forward only result set which had reached the end, or in other words was position at after last row.

Corrected ArrayIndexOutOfBoundsException when positioning from before­First

Corrected ArrayIndexOutOfBoundsException or eternal loop occurring when a scrollable cursor has been started (at least one row fetched) and positioned in the result set, then positioned on before first (such as using ResultSet.absolute(0), and then positioned near the end of a result set whose size must also exceed the size of one server response package.

This error was introduced with version 2.1.

Corrected positioning for large negative values for ResultSet.absolute

Previously, when starting the cursor (the first positioning call of the result set), with a call to ResultSet.absolute(-n) where n is equal to the size of the result set plus one, ResultSet.isBeforeFirst was incorrectly returning false. Also, ResultSet.getRow() did not return 0 as expected.

This error was introduced with version 2.1.

Corrections in 3.38

FLOAT(p) parameters could be partially corrupted when p is even

When FLOAT(p) parameters were set, the value could sometimes be corrupt for even values of p, when the value was set using a call to PreparedStatement.setInt or PreparedStatement.setLong, and that the number of digits in the integer exceeded the precision.

That is, FLOAT(2)-parameters was vulnerable for values 100 and up, FLOAT(4) was vulnerable for values 10000 and up, etc.

Note:No corrupted values were ever stored in tables.

Incorrect character values in streams returned by ResultSet.getAsciiStream and CallableStatement.getAsciiStream

Character codes in the range 128-255 was not returned properly when calling InputStream.read() on streams returned by ResultSet.getAsciiStream and CallableStatement.getAsciiStream. Instead a negative character value was returned.

Characters were returned correct by InputStream.read(byte[]) and InputStream.read(byte[],int,int).

Parameters were required to be set before statement being executed

Older drivers required all parameters of a PreparedStatement to always be set after the statement was executed. This is no longer the case. Parameters now retain their values through successive executions of the statement. For example, while the below sequence previously inserted only the tuple (1,2), it now inserts the tuples (1,2) and (1,3).

PreparedStatement ps = con.prepareStatement("insert into A values (?,?)");

ps.setInt(1,1);

ps.setInt(2,2);

ps.execute();

ps.setInt(2,3);

ps.execute();

 

The older behavior was not compatible with the JDBC specification which in section 13.2.2 specifically states that "the values set for the parameter markers of a PreparedStatement object are not reset when it is executed".

Error handling when adding parameter sets to batches

Previously, when an error occurred during the last PreparedStatement.addBatch, the batch was left in an error state making it impossible to execute the batch until the error was corrected, for example by adding another parameter set. The error seen during the call to PreparedStatement.executeBatch was -22065, SQLSTATE HY010, with the text "Must call addBatch() before executing the batch".

Corrections in 3.37

Internal error on timeouts when using local shared memory communication

In previous versions there was a chance there was an internal error -22046 with the text "An internal error occurred in readFromServer ([...])", if a garbage collection occurred at the same time a server request timed out if local shared memory communication was used.

(If the timeout was not set with Statement.setQueryTimeout, or any other communication protocol than local shared memory was used (JDBC URL starting with anything other than jdbc:mimer:local:), the error never occurred.)

Corrected problem, NullPointerException if PreparedStatement.setString was called after PreparedStatement.getMoreResults

In previous versions, a NullPointerException would occur if PreparedStatement.setString (or any other setter method) was called after a call to PreparedStatement.getMoreResults. This is no longer the case.

Corrections in 3.35

Casting numerical values to Java boolean variables

When calling ResultSet.getBoolean and CallableStatement.getBoolean on a numerical column or output parameter (such as INTEGER, BIGINT, DECIMAL, REAL or DOUBLE PRECISION), true is now returned for all non-zero values. Previously, true was only returned for the value 1, while an exception was thrown for all other non-zero values.

Corrections in 3.31

Connection Hangs When Using a Stream From a Large Object as Input to Another Large Object on the same connection

When obtaining a stream from a large object column (such as by calling Clob.getCharacterStream, ResultSet.getCharacterStream, Blob.getBinaryStream or ResultSet.getBinaryStream) and using this stream as a parameter on the same connection, the JDBC driver will hang, and the process has to be aborted.

Cannot Use the String "0e0" to Set a Floating Point Value

Previously, attempting to use the value "0e0" to set a parameter value of any numeric data type would result in a -22038 numeric conversion error. It now succeeds.

Output Descriptor Overflow Errors (-19053) When Compiling Unusually Large SQL Statements

When compiling large SQL statements, specifically with many parameters, an output descriptor overflow error (-19053) could occur. The number of parameters for the error to occur was about 350.

Finalized Connections May Stall the Garbage Collector

In versions prior to 3.31, connections being finalized issued a server request to end the connection. This could take some time, thus stalling the garbage collector. Finalized connections no longer issue this request, but rather close the network connection.

Extra Zero Characters Appended to Character Columns With UTF-16 Surro­gate Characters

When setting a NCHAR or NVARCHAR column with a value containing UTF-16 surrogate characters, one or more zero characters was inserted at the end of the character string. For example, inserting a string containing the character MUSICAL SYMBOL G CLEF (0x1d11e) which in a Java String is represented by the char pair 0xd834 and 0xdd1e, the resulting characters in the database would be 0x1d11e and 0x00000.

The problem was introduced in 3.30.

Warning For TYPE_SCROLL_SENSITIVE Cursor

The cursor modes which are supported in Mimer are TYPE_FORWARD_ONLY and TYPE_SCROLL_INSENSITIVE.  This means, in Mimer a cursor is always either forward only or scrollable, and scrollable cursors are always insensitive to changes made by other statements and other transactions. (This is in database terms called "cursor stability" and is a basic characteristic of Mimer.)

The third JDBC cursor mode TYPE_SCROLL_SENSITIVE is supported as an option, but the underlying database will never show any changes in the result set - the cursor is always stable. In this case the JDBC driver issues a warning saying that an TYPE_SCROLL_INSENSITIVE result set was used instead.

The problem was that this warning was not shown until the statement was executed. This is now changed so that the warning is shown directly when the statement is created.

PreparedStatement.setObject Failed with Byte and Short Data Types

Previously any attempt to set a parameter using PreparedStatement.setObject (or CallableStatement.setObject) with a Byte or Short data type would throw an SQLException with the error code -22006. This is now corrected.

Corrections in 3.30

Statement Leak When Executing Statements In a Program Ident Without Ever Leaving the Ident

Previous versions of the driver retained a strong reference to all created Statement (or PreparedStatement or CallableStatement) objects until the application leaves the program ident. If the application never leaves the program ident, memory resources may eventually become scarce. The reference was kept even though the statement object was closed properly.

From this version onwards, the statement is delisted once being closed, thus causing properly closed statements to be released properly.

PreparedStatement.setString May Corrupt Parameters Or Cause an ArrayIn­dexOutOfBounds Exception

In version 3.29, applications which set parameters of the type CHARACTER, CHARACTER VARYING, NATIONAL CHARACTER or NATIONAL CHARACTER VARYING using a call to PreparedStatement.setString or CallableStatement.setString may experience ArrayIndexOutOfBounds exceptions during the setString method call. If parameters are set in reverse order (i.e. setting parameter n+1 before n) the exception may have been avoided, but parameter contents may have been corrupted.

Problem was introduced in version 3.29 and corrected in 3.30.

Update Counts Not Reported Properly After Call To PreparedStatement.execu­teUpdate and CallableStatement.executeUpdate

The update count, the number of rows affected by an INSERT, UPDATE or DELETE statement executed through a PreparedStatement or CallableStatement object was reported improperly. The correct behavior is to return the number of rows affected, or -1 if unknown. In the named cases, 1 was incorrectly returned for all cases, regardless of the number of rows affected.

Problem was introduced in 3.28 and corrected in 3.30.

Corrections in 3.29

UTF-16 Surrogate Characters

The JDBC driver now handles UTF-16 surrogate characters properly on all uses, except when storing data into columns of the type NATIONAL CHARACTER LARGE OBJECT (see Surrogate Characters in NATIONAL CHARACTER LARGE OBJECT Data).

Earlier versions of the JDBC driver did not handle UTF-16 surrogate characters in a uniform way which led to various errors including cast errors, truncation errors or that character data was rejected by the server because valid strings was not supplied by the driver.

An UTF-16 surrogate character is a legal Unicode character which cannot be represented using a 16-bit word. These characters are, according to the Unicode standard, represented using two consecutive 16-bit words which together make up the complete character.

Corrections in 3.28

Meta Data Lookup Functions In Multithreaded Applications

Older versions of the JDBC driver experienced threading difficulties when JDBC meta data lookup functions were being called.

Multithreaded applications calling ResultSetMetData.getCatalogName(), ResultSetMetData.getSchemaName(), ResultSetMetData.getTableName(), or ResultSetMetData.getColumnTypeName() simultaneously may experience Connection closed problems. A common situation in which this occurred is when using DbVisualizer and reconnecting to a database.

Meta Data Lookup Functions In Resultsets With Many Columns

Versions prior to version 28 of the JDBC driver may not be able to lookup catalog, schema, table and column type name through the meta data lookup functions ResultSetMetData.getCatalogName(), ResultSetMetData.getSchemaName(), ResultSetMetData.getTableName(), or ResultSetMetData.getColumnTypeName() if the underlying result set contained more than about 360 columns. There is now no such limit.

Note however that there is a known problem with older Mimer servers (prior to 10.1) which in combination with earlier versions of the JDBC driver made the upper limit 120 columns.

Corrections in 3.27

ResultSet.wasNull Reporting Incorrect Null Status For BOOLEAN Columns

The ResultSet.wasNull method is supposed to return whether the most recently retrieved column or output parameter held the SQL NULL value or not. Prior to version 27 this was not working properly in the Mimer JDBC Driver on SQL BOOLEAN data since the value returned by ResultSet.wasNull returned the null value status of the column or output parameter retrieved prior to the last retrieved column or output parameter. If the BOOLEAN column or output parameter was the first one to be retrieved, ResultSet.wasNull always returned false no matter the actual value of the column or output parameter in question.

Update counts not returned properly for WHERE CURRENT operations

Older JDBC drivers did not return update counts for UPDATE WHERE CURRENT and DELETE WHERE CURRENT. 0 was always returned, even though a row was updated or deleted.

The problem affected the return values from the methods Statement.executeUpdate and Statement.getUpdateCount.

Corrections in 3.26

Driver fails to recognize escape character when doing dictionary lookups

Prior to this release, the driver did not recognize SQL LIKE-clause escape characters when doing dictionary lookups through the java.sql.DatabaseMetaData interface.

The proper behavior for an application is that it should ask the driver which character is being used as an escape character in meta data lookups. This is done through the DatabaseetaData.getSearchStringEscape method. In the case of Mimer this will always return an exclamation mark (!). The application must then precede those underscores (_) and percent marks (%) which aren't wildcards with an escape character. Escape characters must also be preceded by an escape character.

The problem corrected in version 3.26 was that the Mimer JDBC driver still treated escape wildcard characters as wildcard characters, thus possibly returning more results than expected.

Corrections in 3.25

Mimer JDBC URL’s did not recognize numerical IPv6 addresses

Earlier versions of the Mimer JDBC driver did not recognize the method to specify numerical IPv6 addresses in URL’s using square brackets which is defined in RFC 2732. For example, the following two URL’s are now recognized properly:

jdbc:mimer://[::1]/odbc_net

jdbc:mimer://[::1]:1360/odbc_net

 

It was, however, possible to use a numerical IPv6 address as an URL attribute, or when using the javax.sql.DataSource interface to make database connections. For example, the following two URL’s were, and are still, working properly:

jdbc:mimer:/odbc_net?serverName=::1

jdbc:mimer:/odbc_net?serverName=::1&portNumber=1360

Enter a program ident with long ident name

Attempts to enter program idents using the ENTER statements and supplying an ident name longer than 18 characters, always failed with a -14006 “Login failure” error. Problem is corrected in Mimer JDBC 3.25.

Corrections in 3.24, 2.24 and 1.24

Invalid internal statement identifier when using a java.sql.Statement object that has been retained

When doing the below, the application received the -19039 “Invalid internal statement identifier” error.

Entering a program ident using the Mimer SQL statement ENTER.

Creating a new java.sql.Statement, java.sql.PreparedStatement or java.sql.CallableStatement

Leaving the program ident using the Mimer SQL statement LEAVE.

Attempting to execute statements created above. These are only available when the program ident entered in step 1 is active.

This error condition is now properly managed, and the user will receive the -22071 error along with a descriptive error message.

For more information about ENTER and LEAVE, please refer to the Mimer SQL Reference Manual.

BOOLEAN columns was shown twice in views

BOOLEAN columns was in earlier versions of their driver shown twice in the views returned by DatabaseMetaData.getTypeInfo and DatabaseMetaData.getColumns. This is now corrected.

Corrections in 3.23 and 2.23

Scrollable cursors created with a SELECT statement with parameter markers did not always perform well before release 23. The symptoms where either that the parameter appeared to be ignored, or the server returns a -10303 “negative overflow occurred in arithmetic operation CHP.”

Corrections in 3.23, 2.23 and 1.23

The DatabaseMetaData.getColumns view could previously return the -10312 error when connected to Mimer SQL 9.1 servers or older. See known problem System Views Raising Error -10312 for more information, as the very same problem still applies to DatabaseMetaData.getTypeInfo().

DatabaseMetaData.getColumns in release 23 clients and newer will avoid the problem.

Corrections in 3.22, 2.22 and 1.22

When using the driver with IBM WebSphere 6, connection attempts may end with a “java.sql.SQLException: Connection is closed” message. This is because the driver did not allow pooled connections (javax.sql.PooledConnection) to be closed after the associated Connection has already been closed. The error was not seen when using Websphere 5 or earlier.

Corrections in 3.21, 2.21 and 1.21

Fetching a scrollable cursor by positioning the cursor on a row relative to the end of the result set (e.g. specifying a negative row number to the ResultSet.absolute method) after the last row of the result set has already been visited produced incorrect results. The problem was introduced in version 20 of the JDBC driver.

Corrections in 3.20, 2.20 and 1.20

Improved error handling

If the connection with the server was lost (or if the server is shut down), earlier JDBC drivers could produce a null pointer exception in some circumstances. The new JDBC driver will produce an appropriate SQLException.

Also, the method Connection.isClosed() will now return true on any connection that has received an SQLException indicating that the connection with the server was lost.

Uninformative error message when connecting to Mimer 8.1 servers and older.

When connecting via TCP/IP to Mimer SQL 8.1 servers and older, which aren't accepting connections from JDBC drivers, applications may receive the uninformative internal error -22046. This problem is related to certain server versions, but JDBC drivers from version 20 can recover from this condition and return a proper error message.

Correction in 3.19, 2.19 and 1.19

Version numbers for servers older than 9.3 was not returned properly by the Mimer JDBC n.18 drivers. This problem was seen in DatabaseMetaData.getProductVersion, DatabasMetaData.getDatabaseMajorVersion and DatabaseMetaData.getDatabaseMinorVersion.

Corrections in 3.18, 2.18 and 1.18

PreparedStatement.setString threw no exception on BOOLEAN data types

Version 17 JDBC drivers did never throw an exception if the application called PreparedStatement.setString with an illegal string. That is, a string that is not ’true’ or ’false’. This is corrected in version 18.

LITERAL_SUFFIX and LITERAL_PREFIX for DATE, TIME, TIMESTAMP and INTERVAL data types

Result sets returned by DatabaseMetaData.getTypeInfo did not contain any data in the columns LITERAL_SUFFIX and LITERAL_PREFIX for data types DATE, TIME, TIMESTAMP and all INTERVAL data types. From version 18, these columns have a relevant value.

This correction applies for all server versions. Using an older JDBC driver against a v9.3.5 Mimer SQL server or later will also return correct values for these columns.

Changed behavior for protocol type tcp

Specifying the protocol TCP in the Mimer JDBC URL, would instruct the driver to connect using the native TCP/IP-stack. From version 18, specifying the TCP protocol makes the driver connect using the Java TCP/IP-stack.

The behavior when the protocol is unspecified has not been changed, that is, the Java TCP/IP-stack is used.

Corrections in 3.16, 2.16 and 1.16

DatabaseMetaData.getColumns returns too many columns

Older versions of the Mimer JDBC driver returned, when calling DatabaseMetaData.getColumns, duplicate rows for BINARY LARGE OBJECT, CHARACTER LARGE OBJECT and NATIONAL CHARACTER LARGE OBJECT columns. For example, querying a table with one CHARACTER column and one BINARY LARGE OBJECT column returned a result set of three rows. One row for the CHARACTER column, and two for the BINARY LARGE OBJECT column. This is now corrected.

DATE/TIME comparison problems

Previous drivers did not recognize TIMESTAMP’s representing a value prior to the timestamp 1000-01-01 00:00:00, DATE values prior to the date 1000-01-01 and TIME values prior to 10:00:00 correctly. Although the driver would retrieve and display those values correctly, comparison operations may fail for identical values, leading to potentially duplicate primary keys, or that query conditions may fail for no obvious reason. These problems are now corrected.

Corrections in 2.14

PreparedStatement batches whose size exactly matched the network buffer size failed

Batches of PreparedStatements failed if data in the entire batch exactly matched the amount of space available in the network buffer.

This could mean, for instance, that a batch of 19 rows would fail, while batches of 18 and 20 rows would succeed.

Corrections in 2.14 and 1.14

Non-public constructor in the Driver-class made applications fail loading the Mimer JDBC driver

Applications that don't rely on DriverManager.getConnection, or the javax.sql.DataSource class, to create a Connection to Mimer, but instead are creating a connection by using the Driver class couldn't load the com.mimer.jdbc.Driver class of the 1.13 and 2.13 Mimer JDBC drivers. More specifically, the following didn't work:

Class dc = Class.forName("com.mimer.jdbc.Driver");

Driver d = (Driver)dc.getInstance();

 

Example of products using this (or similar) techniques, and thus avoiding the DriverManager object, are Sun Java Studio Creator and the Squirrel SQL database viewer.

Reading a BLOB stream might hang the connection

Reading Binary Large Objects through an InputStream (obtained through ResultSet.getBinaryStream) would place the network connection in an inconsistent state, in practice the session would hang, if the size of the object is larger than the size of the default network packet size, and the application tries to read the entire object in one call (InputStream.read(b,off,len) where len is larger than the size of the object). This is no longer the case.

Clarified error texts when streams are closed

The error texts saying that streams have been closed now explain why the stream was closed. This could be of several reasons, the server connection went dead, the transaction was committed or rolled back, the statement in which the result set containing the stream was closed, and so forth. This is now explained in the error message.

Corrections in 2.13 and 1.13

Fetching data might throw an SQLException with vendor code 1

Fetching data (ResultSet.next) could erroneously throw SQLExceptions with vendor code 1. This was wrong and is now corrected.

Large BLOB problem

Whenever BLOB’s was read in several passes from the server, and the application specified a length longer than the actual BLOB, the driver hanged. Many platforms deliver TCP/IP packets in chunks of about 64 kb so this problem would occur when reading BLOB’s larger than that.

Corrections in 2.12 and 1.12

The midjdbc2 driver now fully supports SQL DATE, TIME, and TIMESTAMP data types.

By mistake the Beta release (1.10/2.10) lacked support of the SQL constructs for manipulating session and transaction characteristics, such as SET TRANSACTION READ ONLY. These SQL statements are now supported, see the Mimer SQL Reference Manual for more information.

Scrollable cursors now take the value set by Statement.setFetchDirection into account when selecting fetch strategy on scrollable result sets. This does not apply to 1.12.

A problem which caused a premature end of table when a scrollable cursor has seen the end of the result set, is fetching backwards (using ResultSet.previous) and the fetch size has been set to a value less than the size of the result set. This problem did not apply to the JDBC 1 driver.

When earlier versions did a ResultSet.afterLast or ResultSet.last after setting Statement.maxRows to a value that actually limits the result set size, the cursor was positioned on the wrong row, beyond the end of the result set. This is now corrected.

Corrections in 2.11 and 1.11

Previously an InputStream.skip(n) on a stream derived from a BLOB column, or a CharacterStream.skip(n) on a stream derived from a CLOB or NCLOB column may leave the network state out of sync. This was seen with the error -22046 ’An internal error occurred in ReadFromServer’. This problem is now corrected.

Note:For the JDBC 1 driver, this problem applies to streams derived from the getUnicodeStream method call on CLOB and NCLOB columns.

A problem with large SQL statements has been fixed. SQL statements larger than about 20   000 characters were unable to compile because of an ArrayIndexOutOfBoundsException.

Corrections in 2.10 and 1.10

Previous versions of the driver did not return the correct data type on CallableStatement.getObject calls. The specification states that the object type returned should match whatever type was specified when the output parameter was registered through the CallableStatement.registerOutParameter call. Previously, the object type returned matched the data type on the server.

When calling ResultSet.findColumn, ResultSet.getString(String) and similar column name related methods, the Mimer driver previously did a case sensitive search. This was incorrect. The search should be case insensitive, which it now is.

2.8 and 1.8 versions of the Mimer JDBC driver introduced a problem setting CHARACTER and CHARACTER VARYING columns via a CharacterStream object. The end result lost characters without throwing errors. This is now corrected.

A JDBC driver using a database server with many indexes could have performance problems with the DatabaseMetaData.getSchemas call. This is now corrected for 9.2-servers and later. Unfortunately, since the problem is server related, older servers cannot easily be corrected.

JDBC drivers connecting to Mimer SQL 8.2 servers unexpectedly threw SQLException exceptions when using DatabaseMetaData.getCatalogs or DatabaseMetaData.getUDTs. This is now corrected. Note that neither of these queries should return any rows with Mimer SQL 8.2 servers.

java.sql.Blob and java.sql.Clob objects returned from calls to ResultSet.getBlob and ResultSet.getClob now stay alive throughout the entire transaction. Once the transaction in which the object is created is ended, all calls to the objects will throw a ’transaction has ended’ exception. Previously, these objects could not be used once the resultset was closed.

Corrections in 2.9

Scrollable result sets returned an error when calling setFetchDirection. This is no longer the case.

ResultSet.getString did not return correct characters for å, ä, ö and similar Latin-1 but non-ASCII characters when other default character encoding than ISO 8859-1 was used. This included for instance Macintosh computers. This is now corrected.

Corrections in 2.7

Earlier versions incorrectly returned SQLSTATE 22001 for numeric value out of range. The correct 22003 is now returned.

Procedure calls with large output parameters (typically CHAR(100), VARCHAR(100) or larger) could end with the following exception message:

An internal error occurred in MimConnection.readFromServer (packlen=148, bufLen=100, maxReceive=0).

 

This problem is now corrected.

Batches of statements were not cleared when being executed. This forced the programmer to call Statement.clearBatch() before building another batch. From now on, batches are automatically cleared after being executed.

Corrections in 2.6

Server resources was not released even when the application was properly closing Statement, PreparedStatement and CallableStatement objects. This could sometimes cause the following error when attempting to drop a table:

Error code: -16002, msg: Table locked by another cursor, state: S1000

 

This problem is now corrected.

Corrections in 2.2

Correction of DatabaseMetaData.supportsTransactionIsolationLevel(0) which erroneously returned true.

ResultSet.getConcurrency() and ResultSet.getType() returned wrong values for scrollable cursors.

DatabaseMetaData.getSystemFunctions() returned the nonexisting USERNAME function.

A ResultSet.fetchSize with a large number no longer throws an ArrayIndexException.

ResultSets created from a PreparedStatement or CallableStatement no longer fails on the second .next call.

Corrections in 1.9

ResultSet.getString did not return correct characters for å, ä, ö and similar Latin-1 but non-ASCII characters when other default character encoding than ISO 8859-1 was used. This included for instance Macintosh computers. This is now corrected.

The driver now returns the correct object type when doing CallableStatement.getObject. According to the JDBC specification, getObject should return a Java object whose type corresponds to what type the output parameter was registered to with the CallableStatement.registerOutParameter method call. Earlier drivers always returned the default Java object type.

Corrections in 1.7

Earlier versions incorrectly returned SQLSTATE 22001 for numeric value out of range. The correct 22003 is now returned.

Known Restrictions

The following sections document known restrictions.

Mimer SQL Experience v10.1 Limited Support for Statement.getMaxFieldSize and Statement.setMaxFieldSize

Mimer SQL Experience

There are no support for Statement.setMaxFieldSize and Statement.getMaxFieldSize when connected to a version 10.1 Mimer SQL Experience server.

Mimer SQL Experience v10.1 Native SQL Escape Clause Support

Mimer SQL Experience

The version 10.1 Mimer SQL Experience server does not support the following native SQL escape clauses:

ASCII, for example {fn ASCII(x)}

CHAR, for example {fn CHAR(x)}

BIT_LENGTH, for example {fn BIT_LENGTH(x)}

POSITION of the form {fn POSITION(x in y)}.
(The form {fn POSITION(x,y)} is still supported.)

SUBSTRING of the form {fn SUBSTRING(x from y for z)}.
(The form {fn SUBSTRING(x,y,z)} is still supported.)

DATABASE, {fn DATABASE()}

DAYNAME, {fn DAYNAME(t)}

MONTHNAME, {fn MONTHNAME(t)}

QUARTER, {fn QUARTER(t)

TIMESTAMPADD,
for example {fn TIMESTAMPADD(SQL_TSI_SECOND,t,n)}

TIMESTAMPDIFF,
for example {fn TIMESTAMPDIFF(SQL_TSI_SECOND,t,t2)}

CONVERT, for example {fn CONVERT(x,SQL_CHAR)}

DIFFERENCE, such as {fn DIFFERENCE(x,y)}

ACOS, {fn ACOS(n)}

ASIN, {fn ASIN(n)}

ATAN, {fn ATAN(n)}

ATAN2, {fn ATAN2(n,m)}

COS, {fn COS(n)}

COT, {fn COT(n)}

PI, {fn PI()}

DEGREES, {fn DEGREES(n)}

EXP, {fn EXP(n)}

LOG, {fn LOG(n)}

LOG10, {fn LOG10(n)}

POWER, {fn POWER(n,m)}

RADIANS, {fn RADIANS(n)}

SIN, {fn SIN(n)}

SQRT, {fn SQRT(n)}

TAN, {fn TAN(n)}

NOW, {fn NOW()}

Optional JDBC 2 features not supported:

Connection timeout

Updatable result sets

Searching for data in large objects using the Blob.position or Clob.position methods

java.sql.Array java objects (dependent on the SQL ARRAY data type)

java.sql.Ref java object (dependent on the SQL REF data type)

Type inheritance

Typed tables and typed table inheritance

Referring to procedure and function parameters by name

The JAVA_OBJECT user defined type

Optional JDBC 3 features not supported:

Updating parts of an existing large object using Blob.setBytes or Clob.setBytes

Truncating an existing large object using Blob.truncate or Clob.truncate

Transaction savepoints

Time zones

Support for the SQL DATALINK type and setting and retrieving java.net.URL objects

Retrieving values of auto generated keys

Known Problems

This section describes the known problems with Mimer JDBC.

Surrogate Characters in NATIONAL CHARACTER LARGE OBJECT Data

When storing large object data, current Mimer SQL servers require the client and/or application to supply the size and length of the large object in advance prior to actually storing the data. This poses a problem if the data contains UTF-16 surrogate characters, since the application will know the length of the data by the number of UTF-16 code points, while the server regards the length as being the number of Unicode characters. The number of Unicode characters may therefore be less than the number of UTF-16 code points in the input data.

In these situations, database objects of the type NATIONAL CHARACTER LARGE OBJECT will be padded with zero characters up to the length originally specified. When at a later date the object is retrieved, it may appear to have grown in length. The actual number of characters grown equals the number of surrogate characters in the input data.

System Views Raising Error -10312

The system metadata returned by DatabaseMetaData.getTypeInfo, DatabaseMetaData.getProcedureColumns, and DatabaseMetaData.getBestRowIdentifier from Mimer SQL 9.1 servers or older may return -10312 “numeric value out of range”.

The error will not appear if no user created domains are present and returned by the views, or if less than 32768 system objects have been created in the database.

Statements Never Executed By java.sql.Statement.executeUpdate()

When issuing the statements ENTER, LEAVE, LEAVE RETAIN, SET DATABASE, SET DATABANK, and SET SHADOW are reported as having completed successfully, but they are actually never executed on the server. UPDATE STATISTICS and DELETE STATISTICS always return with an “Invalid internal DDU identifier” error.

All these statements are executed properly when being executed either using a java.sql.PreparedStatement or a java.sql.CallableStatement, but also using the java.sql.Statement.execute method.

The problem appeared in Mimer SQL servers in version 9.3.1 and was corrected in version 9.3.7G.

Update Counts on Errors in Batched Statements

Whenever an error occurs in a batched Statement, the driver is unable to return the correct information about the number of executed rows. The correct behavior is to return an integer array within a thrown BatchUpdateException object whose length corresponds to the number of batch statements. The Mimer driver is now returning an integer array with one entry per statement, with all entries set to 0.