Frequently Asked Questions

I Have a Problem or Feature Request
Are there Known Bugs? When is the Next Release?
Is this Database Engine Open Source?
My Query is Slow
How to Create a New Database?
How to Connect to a Database?
Where are the Database Files Stored?
What is the Size Limit (Maximum Size) of a Database?
Is it Reliable?
Why is Opening my Database Slow?
Column Names are Incorrect?
Float is Double?
Is the GCJ Version Stable? Faster?
How to Translate this Project?

I Have a Problem or Feature Request

Please read the support checklist.

Are there Known Bugs? When is the Next Release?

Usually, bugs get fixes as they are found. There is a release every few weeks. Here is the list of known and confirmed issues:

Apache Harmony: there seems to be a bug in Harmony that affects H2. See HARMONY-6505.
Tomcat and Glassfish 3 set most static fields (final or non-final) to null when unloading a web application. This can cause a NullPointerException in H2 versions 1.1.107 and older, and may still not work in newer versions. Please report it if you run into this issue. In Tomcat >= 6.0 this behavior can be disabled by setting the system property org.apache.catalina.loader.WebappClassLoader.ENABLE_CLEAR_REFERENCES=false, however Tomcat may then run out of memory. A known workaround is to put the h2*.jar file in a shared lib directory (common/lib).
Some problems have been found with right outer join. Internally, it is converted to left outer join, which does not always produce the same results as other databases when used in combination with other joins.
When using Install4j before 4.1.4 on Linux and enabling pack200, the h2*.jar becomes corrupted by the install process, causing application failure. A workaround is to add an empty file h2*.jar.nopack next to the h2*.jar file. This problem is solved in Install4j 4.1.4.

For a complete list, see Open Issues.

Is this Database Engine Open Source?

Yes. It is free to use and distribute, and the source code is included. See also under license.

My Query is Slow

Slow SELECT (or DELETE, UPDATE, MERGE) statement can have multiple reasons. Follow this checklist:

Run ANALYZE (see documentation for details).
Run the query with EXPLAIN and check if indexes are used (see documentation for details).
If required, create additional indexes and try again using ANALYZE and EXPLAIN.
If it doesn't help please report the problem.

How to Create a New Database?

By default, a new database is automatically created if it does not yet exist. See Creating New Databases.

How to Connect to a Database?

The database driver is org.h2.Driver, and the database URL starts with jdbc:h2:. To connect to a database using JDBC, use the following code:

Class.forName("org.h2.Driver");
Connection conn = DriverManager.getConnection("jdbc:h2:~/test", "sa", "");

Where are the Database Files Stored?

When using database URLs like jdbc:h2:~/test, the database is stored in the user directory. For Windows, this is usually C:\Documents and Settings\<userName>. If the base directory is not set (as in jdbc:h2:test), the database files are stored in the directory where the application is started (the current working directory). When using the H2 Console application from the start menu, this is <Installation Directory>/bin. The base directory can be set in the database URL. A fixed or relative path can be used. When using the URL jdbc:h2:file:data/sample, the database is stored in the directory data (relative to the current working directory). The directory is created automatically if it does not yet exist. It is also possible to use the fully qualified directory name (and for Windows, drive name). Example: jdbc:h2:file:C:/data/test

What is the Size Limit (Maximum Size) of a Database?

See Limits and Limitations.

Is it Reliable?

That is not easy to say. It is still a quite new product. A lot of tests have been written, and the code coverage of these tests is very high. Randomized stress tests are run regularly. But there are probably still bugs that have not yet been found (as with most software). Some features are known to be dangerous, they are only supported for situations where performance is more important than reliability. Those dangerous features are:

Using the transaction isolation level READ_UNCOMMITTED (LOCK_MODE 0) while at the same time using multiple connections.
Disabling database file protection using (setting FILE_LOCK to NO in the database URL).
Disabling referential integrity using SET REFERENTIAL_INTEGRITY FALSE.

In addition to that, running out of memory should be avoided. In older versions, OutOfMemory errors while using the database could corrupt a databases.

Some areas of this database are not fully tested. When using one of those features for production, please ensure your use case is well tested (if possible with automated test cases). Those areas are:

Platforms other than Windows XP, Linux, Mac OS X, or JVMs other than Sun 1.5 or 1.6
The feature MULTI_THREADED
The features AUTO_SERVER and AUTO_RECONNECT
The file locking method 'Serialized'
The MVCC (multi version concurrency) mode
Cluster mode, 2-phase commit, savepoints
24/7 operation
Some operations on databases larger than 500 MB may be slower than expected
The optimizer may not always select the best plan
Fulltext search
Operations on LOBs over 2 GB

Areas considered experimental are:

The PostgreSQL server
Multi-threading within the engine using SET MULTI_THREADED=1
Compatibility modes for other databases (only some features are implemented)
The soft reference cache (CACHE_TYPE=SOFT_LRU). It might not improve performance, and out of memory issues have been reported.

Some users have reported that after a power failure, the database cannot be opened sometimes. In this case, use a backup of the database or the Recover tool. Please report such problems. The plan is that the database automatically recovers in all situations.

Column Names are Incorrect?

For the query SELECT ID AS X FROM TEST the method ResultSetMetaData.getColumnName() returns ID, I expect it to return X. What's wrong?

This is not a bug. According the the JDBC specification, the method ResultSetMetaData.getColumnName() should return the name of the column and not the alias name. If you need the alias name, use ResultSetMetaData.getColumnLabel(). Some other database don't work like this yet (they don't follow the JDBC specification). If you need compatibility with those databases, use the Compatibility Mode, or set the system property h2.aliasColumnName.

This also applies to DatabaseMetaData calls that return a result set. The columns in the JDBC API are column labels, not column names.

Float is Double?

For a table defined as CREATE TABLE TEST(X FLOAT) the method ResultSet.getObject() returns a java.lang.Double, I expect it to return a java.lang.Float. What's wrong?

This is not a bug. According the the JDBC specification, the JDBC data type FLOAT is equivalent to DOUBLE, and both are mapped to java.lang.Double. See also Mapping SQL and Java Types - 8.3.10 FLOAT.

Why is Opening my Database Slow?

To find out what the problem is, use the H2 Console and click on "Test Connection" instead of "Login". After the "Login Successful" appears, click on it (it's a link). This will list the top stack traces. Then either analyze this yourself, or post those stack traces in the Google Group.

To find out what the problem is, open the database in embedded mode using the H2 Console. This will print progress information. If you have many lines with 'Creating index' it is an indication that the database was not closed the last time.

Other possible reasons are: the database is very big (many GB), or contains linked tables that are slow to open.

Is the GCJ Version Stable? Faster?

The GCJ version is not as stable as the Java version. When running the regression test with the GCJ version, sometimes the application just stops at what seems to be a random point without error message. Currently, the GCJ version is also slower than when using the Sun VM. However, the startup of the GCJ version is faster than when using a VM.

How to Translate this Project?

For more information, see Build/Translating.