H2 Database Engine 1.1.113

H2 is an SQL database engine written in Java (but also available as a native binary). JDBC and ODBC APIs are supported.
Embedded and server modes are available. A Web console application is included. Clustering is supported.
H2 Database Engine is a web based java database engine.

Main features:
- Fast database engine
- Free, source code is included
- Supports standard SQL
- Written in Java
- Disk based or in-memory databases
- Browser base Console application
- JDBC API
- Limited ODBC support
- Embedded and client/server (network) mode
- High availablility support (clustering / failover)
- Wide range of data types including large objects (BLOB/CLOB)
- Strong security features (SSL, users, roles, encrypted files)
- Multiple connections, table level locking
- Cost based optimizer, using a genetic algorithm for complex queries
- Transaction support (serializable transaction isolation)
- Zero-administration, automatic recovery
- Large resultset, external sorting
- Scrollable and updatable resultset support
- Read only views and inline views
- Inner and outer joins, subqueries
- Many functions already built-in
- Triggers and Java functions / stored procedures
- Referential integrity / foreign key constraints with cascade, check constraints
- Multiple schema support
- Compatibility modes for HSQLDB, MySQL and PostgreSQL
- Sequence and autoincrement columns
- Well tested (high code coverage, randomized stress tests)
- Small footprint (smaller than 1 MB)
- Uses a small number of database files
- Can be compiled to native code using GCJ
- Primary keys, multiple index types (b-tree, linear hash, tree, hash)
- ORDER BY, GROUP BY, HAVING, UNION, LIMIT
- Information Schema
- Multiple connections
- Collation support
- EXPLAIN PLAN support
- The database can generate SQL script files
- Support for linked tables, and a built-in virtual range table
- Automatic re-compilation of prepared statements
- Sophisticated trace options
- Low memory requirements
- Easy to understand exception messages
- Standard handling of NULL values
- Multilanguage console application (at this time, English and German).

Enhancements
- Shell tool: the built-in commands EXIT, HELP, ?, LIST, and so on didnt work with a semicolon at the end.
- JDK 1.5 is now required to build the jar file. However it is still possible to create a jar file for Java 1.4. For details, see buildRelease.sh and buildRelease.bat. As an alternative, compile using JDK 1.5 or 1.6 and use Retrotranslator to create a Java 1.4 version http://retrotranslator.sourceforge.net/).
- When deleting or updating many rows in a table, the space in the index file was not re-used in the default mode (persistent database, b-tree index, LOG=1). This caused the index file to grow over time. Workarounds were to delete and re-created the index file, alter the table (add a remove a column), or append ;LOG=2 to the database URL. To disable the change, set the system property h2.reuseSpaceBtreeIndex to false.
- Identifiers with a digit and then a dollar sign didnt work. Example: A1$B.
- MS SQL Server compatibility: support for linked tables with NVARCHAR, NCHAR, NCLOB, and LONGNVARCHAR.
- Android: Workaround for a problem when using read-only databases in zip files (skip seems to be implemented incorrectly on the Android system).
- Calling execute() or prepareStatement() with null as the SQL statement now throws an exception.
- Benchmark: the number of executed statements was incorrect. The H2 database was loaded at the beginning of the test to collect results, now it is loaded at the very end. Thanks to Fred Toussi from HSQLDB for reporting those problems. However the changed do not affect the relative performance.
- H2 Console: command line settings are no longer stored in the properties file. They are now only used for the current process, except if they are explicitly saved.
- Cache: support for a second level soft-references cache. To enable it, append ;CACHE_TYPE=SOFT_LRU (or SOFT_TQ) to the database URL, or set the system property h2.cacheTypeDefault to "SOFT_LRU" / "SOFT_TQ". Enabling the second level cache reduces performance for small databases, but speeds up large databases. It makes sense to use it if the available memory size is unknown. Thanks a lot to Jan Kotek!