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.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 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 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.31

• 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 Datatypes

  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 ArrayIndexOutOfBounds 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.executeUpdate 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.

• 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

• 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.

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