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.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 3.20, 2.20 and 1.20

• 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 only sorted on DATA_TYPE (the integer type code). Now, thw rows are sorted on DATA_TYPE, core data types first then domains, and TYPE_NAME.

• 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 datatype FLOAT(n) which can store a floating point number with n digits of mantissa and an exponent ranging from -999 to 999.

  This datatype 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 datatype 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 datatype DOUBLE PRECISION for Java double and the Mimer datatype REAL for Java float.

  Note that the Mimer datatype 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 zeroes to its declared precision (a FLOAT(15) could return "1.00000000000000"). This version will not add those zeroes (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 licence 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 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.

• Improved default connection values for MIDP drivers

  The MIDP driver can only connect using the javax.sql.DataSource compliant com.mimer.jdbc.MimerDataSource class. From version 14 onwards, MIDP drivers default all values (host name, database name, port number) to those required to connect to the local database 'db'. This is the default name of the local database on Symbian devices.

  Ident name and password must always be completed by the application.

Corrections in 2.14 and 1.14

• MIDP:Reduced network buffers

  MIDP drivers has from the start only utilized network buffers of about 10 kb. Unfortunately, at times the driver would allocate network buffers larger than necessary. This is no longer the case. The programmer might influence the size of the network buffer by using the ResultSet.setFetchSize function. If this function is not called, the driver will use a fetch size corresponding to a size of about 10 kb.

• 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. On smaller platforms, such as the Sony Ericsson P800 mobile telephone, the problem is more evident since the MIDP environment on that platform delivers TCP/IP packets in sizes of 512 bytes. This problem is now corrected.

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

• Mimer SQL Mobile does not support .mark() on .getBinaryStream, .getAsciiStream and .getCharacterStream. Use Bufferedxxx manually.
• The following optional features described in the JDBC 2 specification are not yet supported:
  • Connection timeout
  • Updatable ResultSets
  • The java.sql.Blob.position and java.sql.Clob.position methods
  • The java.sql.Array, java.sql.Ref, and java.sql.Struct objects among with the getter and setter methods for the objects.

Known Problems

This section describes the known problems with Mimer JDBC.

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.

Unable to Connect to "localhost" on MIDP Devices

When setting the database host name using a call to DataSource.setServerName() the value is used as it is to connect to the host in question. If the application is running on a device such as a telephone, this device may not have access to a name server, and it may not map commonly used names such as "localhost". Attempting to connect to "localhost" will in this case return with an error. The solution is to use the IP-address equivalent of localhost "127.0.0.1". Better yet, 127.0.0.1 is the default so if the desired host is the same machine, the server name need not to be set.

This problem is known to apply to Nokia S60 devices.

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.

Mimer Information Technology AB Voice: +46 18 780 92 00 Fax: +46 18 780 92 40 info@mimer.se