#When using Java Web Start / JNLP (Java Network Launch Protocol), permissions tags must be set in the .jnlp file, and the application .jar file must be signed. Otherwise, when trying to write to the file system, the following exception will occur: java.security.AccessControlException: access denied (java.io.FilePermission ... read). Example permission tags:
@~faq_1010_h3
#Are there any known bugs? When is the next release?
@~faq_1011_p
#Usually, bugs get fixes as they are found. There is a release every few weeks. Here is the list of known and confirmed issues as of 2007-08-02:
@~faq_1012_li
#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.
@~faq_1013_h3
#Is this Database Engine Open Source?
@~faq_1014_p
#Yes. It is free to use and distribute, and the source code is included. See also under license.
@~faq_1015_h3
#My query is slow
@~faq_1016_p
#Slow SELECT (or DELETE, UPDATE, MERGE) statement can have multiple reasons. Follow this checklist:
@~faq_1017_li
#Run ANALYSE (see documentation for details).
@~faq_1021_h3
#How to Create a New Database?
@~faq_1022_p
#By default, a new database is automatically created if it does not yet exist.
@~faq_1023_h3
#How to Connect to a Database?
@~faq_1024_p
#The database driver is <code>org.h2.Driver</code> , and the database URL starts with <code>jdbc:h2:</code> . To connect to a database using JDBC, use the following code:
@~faq_1025_h3
#Where are the Database Files Stored?
@~faq_1026_p
#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 must exist. It is also possible to use the fully qualified directory (and for Windows, drive) name. Example: jdbc:h2:file:C:/data/test
@~faq_1027_h3
#What is the Size Limit (maximum size) of a Database?
@~faq_1028_p
#The theoretical limit is currently 256 GB for the data. This number is excluding BLOB and CLOB data: Every CLOB or BLOB can be up to 256 GB as well. The size limit of the index data is 256 GB as well.
@~faq_1030_h3
#Is it Reliable?
@~faq_1031_p
#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 as this is a relatively new product, there are probably some problems that have not yet been found. Areas that are not 100% tested:
@~faq_1032_li
#Platforms other than Windows XP and the Sun JVM 1.4 and 1.5
@~faq_1044_p
#Areas considered Experimental:
@~faq_1045_li
#ODBC driver and the GCJ native version on Windows
@~faq_1049_h3
#Is the GCJ version stable? Faster?
@~faq_1050_p
#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.
@~features_1202_h2
#Connection Modes
@~features_1203_p
#The following connection modes are supported:
@~features_1204_li
#Local connections using JDBC (embedded)
@~features_1205_li
#Remote connections using JDBC over TCP/IP (client/server)
@~features_1208_h2
#Database URL Overview
@~features_1209_p
#This database does support multiple connection modes and features when connecting to a database. This is achieved using different database URLs. The settings in the URLs are not case sensitive.
#The database URL for connecting to a local database is <code>jdbc:h2:[file:][<path>]<databaseName></code> . The prefix <code>file:</code> is optional. If no or only a relative path is used, then the current working directory is used as a starting point. The case sensitivity of the path and database name depend on the operating system, however it is suggested to use lowercase letters only. The database name must be at least three characters long (a limitation of File.createTempFile). To point to the user home directory, use ~/, as in: jdbc:h2:~/test.
@~features_1262_p
#In some cases, only one connection to a memory-only database is required. This means the database to be opened is private. In this case, the database URL is <code>jdbc:h2:mem:</code> Opening two connections within the same virtual machine means opening two different (private) databases.
@~features_1265_h2
#Connecting to a Database with File Encryption
@~features_1269_p
#The following file locking methods are implemented:
@~features_1270_li
#The default method is 'file' and uses a watchdog thread to protect the database file. The watchdog reads the lock file each second.
@~features_1271_li
#The second method is 'socket' and opens a server socket. The socket method does not require reading the lock file every second. The socket method should only be used if the database files are only accessed by the one (and always the same) computer.
@~features_1273_p
#To open the database with a different file locking method, use the parameter 'FILE_LOCK'. The following code opens the database with the 'socket' locking method:
@~features_1274_p
#The following code forces the database to not create a lock file at all. Please note that this is unsafe as another process is able to open the same database, possibly leading to data corruption:
@~features_1276_h2
#Opening a Database Only if it Already Exists
@~features_1279_h3
#Delayed Database Closing
@~features_1280_p
#Usually, the database is closed when the last connection to it is closed. In some situations this slows down the application, for example when it is not possible leave the connection open. The automatic closing of the database can be delayed or disabled with the SQL statement SET DB_CLOSE_DELAY <seconds>. The seconds specifies the number of seconds to keep a database open after the last connection to it was closed. For example the following statement will keep the database open for 10 seconds:
@~features_1281_p
#The value -1 means the database is never closed automatically. The value 0 is the default and means the database is closed when the last connection is closed. This setting is persistent and can be set by an administrator only. It is possible to set the value in the database URL: <code>jdbc:h2:~/test;DB_CLOSE_DELAY=10</code> .
@~features_1282_h3
#Don't Close the Database when the VM Exits
@~features_1284_h2
#Log Index Changes
@~features_1286_h3
#Ignore Unknown Settings
@~features_1290_h2
#Custom File Access Mode
@~features_1292_p
#For more information see <a href="advanced.html#durability_problems">Durability Problems</a> . On many operating systems the access mode 'rws' does not guarantee that the data is written to the disk.
@~features_1293_h2
#Multiple Connections
@~features_1294_h3
#Opening Multiple Databases at the Same Time
@~features_1295_p
#An application can open multiple databases at the same time, including multiple connections to the same database. The number of open database is only limited by the memory available.
@~features_1302_p
#Usually, SELECT statement will generate read locks. This includes subqueries. Statements that modify data use write locks. It is also possible to lock a table exclusively without modifying data, using the statement SELECT ... FOR UPDATE. The statements COMMIT and ROLLBACK releases all open locks. The commands SAVEPOINT and ROLLBACK TO SAVEPOINT don't affect locks. The locks are also released when the autocommit mode changes, and for connections with autocommit set to true (this is the default), locks are released after each statement. Here is an overview on what statements generate what type of lock:
@~features_1303_th
#Type of Lock
@~features_1304_th
#SQL Statement
@~features_1305_td
#Read
@~features_1306_td
#SELECT * FROM TEST
@~features_1320_p
#The number of seconds until a lock timeout exception is thrown can be set separately for each connection using the SQL command SET LOCK_TIMEOUT <milliseconds>. The initial lock timeout (that is the timeout used for new connections) can be set using the SQL command SET DEFAULT_LOCK_TIMEOUT <milliseconds>. The default lock timeout is persistent.
@~features_1321_h2
#Database File Layout
@~features_1323_th
#File Name
@~features_1324_th
#Description
@~features_1326_td
#test.data.db
@~features_1327_td
#Data file
@~features_1367_h3
#Moving and Renaming Database Files
@~features_1368_p
#Database name and location are not stored inside the database names.
@~features_1369_p
#While a database is closed, the files can be moved to another directory, and they can be renamed as well (as long as all files start with the same name).
@~features_1371_h3
#Backup
@~features_1373_p
#To backup data while the database is running, the SQL command SCRIPT can be used.
@~features_1374_h2
#Logging and Recovery
@~features_1376_p
#Please note that index file updates are not logged by default. If the database is opened and recovery is required, the index file is rebuilt from scratch.
@~features_1379_h2
#Compatibility Modes
@~features_1381_th
#Mode
@~features_1382_th
#Differences
@~features_1383_td
#PostgreSQL
@~features_1384_td
#Concatenation of a NULL with another value results in NULL. Usually, the NULL is treated as an empty string if only one of the operators is NULL, and NULL is only returned if both values are NULL.
@~features_1389_h2
#Using the Trace Options
@~features_1390_p
#To find problems in an application, it is sometimes good to see what database operations where executed. This database offers the following trace features:
@~features_1391_li
#Trace to System.out and/or a file
@~features_1392_li
#Support for trace levels OFF, ERROR, INFO, and DEBUG
@~features_1396_h3
#Trace Options
@~features_1397_p
#The simplest way to enable the trace option is setting it in the database URL. There are two settings, one for System.out (TRACE_LEVEL_SYSTEM_OUT) tracing, and one for file tracing (TRACE_LEVEL_FILE). The trace levels are 0 for OFF, 1 for ERROR (the default), 2 for INFO and 3 for DEBUG. A database URL with both levels set to DEBUG is:
@~features_1398_p
#The trace level can be changed at runtime by executing the SQL command <code>SET TRACE_LEVEL_SYSTEM_OUT level</code> (for System.out tracing) or <code>SET TRACE_LEVEL_FILE level</code> (for file tracing). Example:
@~features_1399_h3
#Setting the Maximum Size of the Trace File
@~features_1403_p
#You need to filter out the lines without /**/ to get the Java source code. In Windows, a simple way to do that is:
@~features_1406_h3
#Enabling the Trace Option at Runtime by Manually Creating a File
@~features_1408_p
#Example: if a database is called 'test', then the file to start tracing is 'test.trace.db.start'. The database engine tries to delete this file when it detects it. If trace is enabled using the start file, the trace level is not persistent to the database, and trace is switched back to the level that was set before when connecting to the database. However, if the start file is read only, the database engine cannot delete the file and will always enable the trace mode when connecting.
@~features_1409_h2
#Read Only Databases
@~features_1415_p
#It is possible to install a database event listener to detect low disk space situations early on (when only 1 MB if space is available). To do this, use the SQL statement SET DATABASE_EVENT_LISTENER. The listener can also be set at connection time, using an URL of the form jdbc:h2:~/test;DATABASE_EVENT_LISTENER='com.acme.DbListener' (the quotes around the class name are required). See also the DatabaseEventListener API.
@~features_1416_h3
#Opening a Corrupted Database
@~features_1418_h2
#Computed Columns / Function Based Index
@~features_1420_p
#When inserting data, it is not required (better: not allowed) to specify a value for the upper-case version of the column, because the value is generated. But you can use the column when querying the table:
@~features_1421_h2
#Multi-Dimensional Indexes
@~features_1423_p
#Currently, Z-order (also called N-order or Morton-order) is used; Hilbert curve could also be used, but the implementation is more complex. The algorithm to convert the multi-dimensional value is called bit-interleaving. The scalar value is indexed using a B-Tree index (usually using a computed column).
@~features_1425_h2
#Using Passwords
@~features_1426_h3
#Using Secure Passwords
@~features_1427_p
#Remember that weak passwords can be broken no matter of the encryption and security protocol. Don't use passwords that can be found in a dictionary. Also appending numbers does not make them secure. A way to create good passwords that can be remembered is, take the first letters of a sentence, use upper and lower case characters, and creatively include special characters. Example:
@~features_1428_p
#i'sE2rtPiUKtT (it's easy to remember this password if you know the trick)
@~features_1429_h3
#Passwords: Using Char Arrays instead of Strings
@~features_1431_p
#An attacker might have access to the swap file of the operating system. It is therefore a good idea to use char arrays instead of Strings to store passwords. Char arrays can be cleared (filled with zeros) after use, and therefore the password will not be stored in the swap file.
@~features_1434_h3
#Passing the User Name and/or Password in the URL
@~features_1436_h2
#User Defined Functions and Stored Procedures
@~features_1438_p
#The Java function must be registered in the database by calling CREATE ALIAS:
@~features_1440_h3
#Function Data Type Mapping
@~features_1452_h2
#Triggers
@~features_1454_p
#The connection can be used to query or update data in other tables. The trigger then needs to be defined in the database:
@~features_1456_h2
#Compacting a Database
@~features_1458_p
#See also the sample application org.h2.samples.Compact. The commands SCRIPT / RUNSCRIPT can be used as well to create the a backup of a database and re-build the database from the script.
@~features_1459_h2
#Cache Settings
@~features_1461_p
#This database supports two cache page replacement algorithms: LRU (the default) and 2Q. For LRU, the pages that were least frequently used are removed from the cache if it becomes full. The 2Q algorithm is a bit more complicated, basically two queues are used. The 2Q algorithm is more resistant to table scans, however the overhead is a bit higher compared to the LRU. To use the cache algorithm 2Q, use a database URL of the form jdbc:h2:~/test;CACHE_TYPE=TQ. The cache algorithm can not be changed once the database is open.
@~features_1463_h2
#Why Java
@~features_1465_li
#Very simple to integrate in Java applications
@~features_1466_li
#Support for many different platforms
@~features_1470_p
#Some people think that Java is still too slow for low level operations, but this is not the case (not any more). In general, the code can be written a lot faster than using C or C++. Like that, it is possible to concentrate on improving the algorithms (that make the application faster) rather than porting the code and dealing with low level stuff (such as memory management or dealing with threads). Garbage collection is now probably faster than manual memory management.
@~features_1471_p
#A lot of features are already built in (for example Unicode, network libraries). It is very easy to write secure code because buffer overflows and such problems can be detected very easily. Some features such as the reflection mechanism can be used for randomized testing.
@~history_1023_h3
#Version 1.0 / 2007-08-02 (Build 56)
@~history_1029_h3
#Version 1.0 / 2007-08-02 (Build 56)
@~history_1029_li
#A server that implements the PostgreSQL protocol is now included and documented. That means, the PostgreSQL ODBC driver can be used to access a H2 database. See in the documentation for details.
@~history_1030_h3
#Version 1.0 / 2007-08-02 (Build 56)
@~history_1030_li
#A new tool to help translation has been implemented: src/tools/org/h2/tools/i18n/PrepareTranslation. This tool can detect delta changes in the original (English) and prepends '#' in translation if the original text was changed. It can also extract text from the user documentation (however, it is incomplete).
@~history_1031_h3
#Version 1.0 / 2007-08-02 (Build 56)
@~history_1031_li
#A new tool to help translation has been implemented: src/tools/org/h2/tools/i18n/PrepareTranslation. This tool can detect delta changes in the original (English) and prepends '#' in translation if the original text was changed. It can also extract text from the user documentation (however, it is incomplete).
@~history_1032_li
#A new tool to help translation has been implemented: src/tools/org/h2/tools/i18n/PrepareTranslation. This tool can detect delta changes in the original (English) and prepends '#' in translation if the original text was changed. It can also extract text from the user documentation (however, it is incomplete).
@~history_1050_h3
#Version 1.0 / 2007-07-12 (Build 55)
@~history_1056_h3
#Version 1.0 / 2007-07-12 (Build 55)
@~history_1056_li
#New column ID for INFORMATION_SCHEMA.INDEXES, SEQUENCES, USERS, ROLES, RIGHTS, FUNCTION_ALIASES, SCHEMATA, VIEWS, CONSTRAINTS, CONSTANTS, DOMAINS, TRIGGERS.
@~history_1057_h3
#Version 1.0 / 2007-07-12 (Build 55)
@~history_1057_li
#Support for the system property baseDir. This works for embedded databases as well. The setting is supported by the H2 Console using -Dh2.baseDir or -baseDir
@~history_1058_h3
#Version 1.0 / 2007-07-12 (Build 55)
@~history_1058_li
#Support for the system property baseDir. This works for embedded databases as well. The setting is supported by the H2 Console using -Dh2.baseDir or -baseDir
@~history_1059_li
#Support for the system property baseDir. This works for embedded databases as well. The setting is supported by the H2 Console using -Dh2.baseDir or -baseDir
@~history_1076_h3
#Version 1.0 / 2007-06-17 (Build 50)
@~history_1082_h3
#Version 1.0 / 2007-06-17 (Build 50)
@~history_1082_li
#Views support has been partially re-implemented. Views are up to 6 times faster. Compared to regular queries, only 20% overhead. Because this is a bigger change, it is not enabled by default. To enable it, set the system property 'h2.indexNew' to true (java -Dh2.indexNew=true ..., or in source code Constants.INDEX_NEW = true). If no problems are found, this will be enabled by default in the next release.
@~history_1083_h3
#Version 1.0 / 2007-06-17 (Build 50)
@~history_1083_li
#File names starting with ~ are now in the user directory (Java system property user.home)
@~history_1084_h3
#Version 1.0 / 2007-06-17 (Build 50)
@~history_1084_li
#File names starting with ~ are now in the user directory (Java system property user.home)
@~history_1085_li
#File names starting with ~ are now in the user directory (Java system property user.home)
@~history_1101_h3
#Version 1.0 / 2007-04-29 (Build 46)
@~history_1107_h3
#Version 1.0 / 2007-04-29 (Build 46)
@~history_1107_li
#SimpleResultSet now has some basic data type conversion features.
@~history_1108_h3
#Version 1.0 / 2007-04-29 (Build 46)
@~history_1108_li
#Unnamed private in-memory database (jdbc:h2:mem:) were not 'private' as documented. Fixed.
@~history_1109_h3
#Version 1.0 / 2007-04-29 (Build 46)
@~history_1109_li
#Unnamed private in-memory database (jdbc:h2:mem:) were not 'private' as documented. Fixed.
@~history_1110_li
#Unnamed private in-memory database (jdbc:h2:mem:) were not 'private' as documented. Fixed.
@~history_1135_h3
#Version 1.0 / 2007-03-04 (Build 44)
@~history_1141_h3
#Version 1.0 / 2007-03-04 (Build 44)
@~history_1141_li
#After renaming a user the password becomes invalid. This is now documented.
@~history_1142_h3
#Version 1.0 / 2007-03-04 (Build 44)
@~history_1142_li
#System sequences (automatically created sequences for IDENTITY or AUTO_INCREMENT columns) are now random (UUIDs) to avoid clashes when merging databases using RUNSCRIPT.
@~history_1143_h3
#Version 1.0 / 2007-03-04 (Build 44)
@~history_1143_li
#System sequences (automatically created sequences for IDENTITY or AUTO_INCREMENT columns) are now random (UUIDs) to avoid clashes when merging databases using RUNSCRIPT.
@~history_1144_li
#System sequences (automatically created sequences for IDENTITY or AUTO_INCREMENT columns) are now random (UUIDs) to avoid clashes when merging databases using RUNSCRIPT.
@~history_1152_h3
#Version 1.0 / 2007-01-30 (Build 41)
@~history_1158_h3
#Version 1.0 / 2007-01-30 (Build 41)
@~history_1158_li
#The Console is now translated to Hungarian thanks to Andras Hideg, and to Indonesian thanks to Joko Yuliantoro
@~history_1159_h3
#Version 1.0 / 2007-01-30 (Build 41)
@~history_1159_li
#Experimental online backup feature using the SQL statement BACKUP TO 'fileName'. This creates a backup in the form of a zip file. Unlike the SCRIPT TO command, the data tables are not locked.
@~history_1160_h3
#Version 1.0 / 2007-01-30 (Build 41)
@~history_1160_li
#Experimental online backup feature using the SQL statement BACKUP TO 'fileName'. This creates a backup in the form of a zip file. Unlike the SCRIPT TO command, the data tables are not locked.
@~history_1161_li
#Experimental online backup feature using the SQL statement BACKUP TO 'fileName'. This creates a backup in the form of a zip file. Unlike the SCRIPT TO command, the data tables are not locked.
@~history_1167_h3
#Version 1.0 / 2007-01-17 (Build 40)
@~history_1173_h3
#Version 1.0 / 2007-01-17 (Build 40)
@~history_1173_li
#Selecting a column using the syntax schemaName.tableName.columnName did not work in all cases.
@~history_1174_h3
#Version 1.0 / 2007-01-17 (Build 40)
@~history_1174_li
#Setting the collation (SET COLLATOR) was very slow on some systems (up to 24 seconds). Thanks a lot to Martina Nissler for finding this problem!
@~history_1175_h3
#Version 1.0 / 2007-01-17 (Build 40)
@~history_1175_li
#Setting the collation (SET COLLATOR) was very slow on some systems (up to 24 seconds). Thanks a lot to Martina Nissler for finding this problem!
@~history_1176_li
#Setting the collation (SET COLLATOR) was very slow on some systems (up to 24 seconds). Thanks a lot to Martina Nissler for finding this problem!
@~history_1179_h3
#Version 1.0 / 2007-01-02 (Build 36)
@~history_1185_h3
#Version 1.0 / 2007-01-02 (Build 36)
@~history_1185_li
#Using ;RECOVER=1 in the database URL threw a syntax exception. Fixed.
@~history_1186_h3
#Version 1.0 / 2007-01-02 (Build 36)
@~history_1186_li
#It was possible to drop the sequence of a temporary tables with DROP ALL OBJECTS, resulting in a null pointer exception afterwards.
@~history_1187_h3
#Version 1.0 / 2007-01-02 (Build 36)
@~history_1187_li
#It was possible to drop the sequence of a temporary tables with DROP ALL OBJECTS, resulting in a null pointer exception afterwards.
@~history_1188_li
#It was possible to drop the sequence of a temporary tables with DROP ALL OBJECTS, resulting in a null pointer exception afterwards.
@~history_1191_h3
#Version 1.0 / 2006-12-17 (Build 34)
@~history_1197_h3
#Version 1.0 / 2006-12-17 (Build 34)
@~history_1197_li
#The RunScript tool can now include other files using a new syntax: @INCLUDE fileName. It was already possible to do that using embedded RUNSCRIPT statements, but not remotely.
@~history_1198_h3
#Version 1.0 / 2006-12-17 (Build 34)
@~history_1198_li
#Can be compiled with JDK 1.6. However, only very few of the JDBC 4.0 features are implemented so far.
@~history_1199_h3
#Version 1.0 / 2006-12-17 (Build 34)
@~history_1199_li
#Can be compiled with JDK 1.6. However, only very few of the JDBC 4.0 features are implemented so far.
@~history_1200_li
#Can be compiled with JDK 1.6. However, only very few of the JDBC 4.0 features are implemented so far.
@~history_1206_h3
#Version 1.0 / 2006-12-03 (Build 32)
@~history_1212_h3
#Version 1.0 / 2006-12-03 (Build 32)
@~history_1212_li
#There was a bug in the database encryption algorithm. The initialization vector was not correctly calculated, and pattern of repeated encrypted bytes where generated for empty blocks in the file. This has been is fixed. The security of the data itself was not compromised, but this was not the intended behavior. If you have an encrypted database, you will need to decrypt the database using the org.h2.tools.ChangePassword (using the old database engine), and encrypt the database using the new engine. Alternatively, you can use the Backup and RunScript tools or the SQL commands SCRIPT and RUNSCRIPT.
@~history_1213_h3
#Version 1.0 / 2006-12-03 (Build 32)
@~history_1213_li
#The SQL statement COMMENT did not work as expected. Many bugs have been fixed in this area. If you already have comments in the database, it is recommended to backup and restore the database, using the Backup and RunScript tools or the SQL commands SCRIPT and RUNSCRIPT.
@~history_1214_h3
#Version 1.0 / 2006-12-03 (Build 32)
@~history_1214_li
#The SQL statement COMMENT did not work as expected. Many bugs have been fixed in this area. If you already have comments in the database, it is recommended to backup and restore the database, using the Backup and RunScript tools or the SQL commands SCRIPT and RUNSCRIPT.
@~history_1215_li
#The SQL statement COMMENT did not work as expected. Many bugs have been fixed in this area. If you already have comments in the database, it is recommended to backup and restore the database, using the Backup and RunScript tools or the SQL commands SCRIPT and RUNSCRIPT.
@~history_1219_h3
#Version 1.0 / 2006-11-20 (Build 31)
@~history_1225_h3
#Version 1.0 / 2006-11-20 (Build 31)
@~history_1225_li
#Direct links to the Javadoc were not working.
@~history_1226_h3
#Version 1.0 / 2006-11-20 (Build 31)
@~history_1226_li
#SCRIPT: New option BLOCKSIZE to split BLOB and CLOB data into separate blocks, to avoid OutOfMemory problems.
@~history_1227_h3
#Version 1.0 / 2006-11-20 (Build 31)
@~history_1227_li
#SCRIPT: New option BLOCKSIZE to split BLOB and CLOB data into separate blocks, to avoid OutOfMemory problems.
@~history_1228_li
#SCRIPT: New option BLOCKSIZE to split BLOB and CLOB data into separate blocks, to avoid OutOfMemory problems.
@~history_1243_h3
#Version 1.0 / 2006-11-03 (Build 30)
@~history_1249_h3
#Version 1.0 / 2006-11-03 (Build 30)
@~history_1249_li
#Linked Tables: Only the first column was linked when linking to PostgreSQL, or a subquery. Fixed.
@~history_1250_h3
#Version 1.0 / 2006-11-03 (Build 30)
@~history_1250_li
#Two simple full text search implementations (Lucene and native) are now included. This is work in progress, and currently undocumented. See test/org/h2/samples/fullTextSearch.sql. To enable the Lucene implementation, you first need to install Lucene, rename FullTextLucene.java.txt to *.java and call 'ant compile'.
@~history_1251_h3
#Version 1.0 / 2006-11-03 (Build 30)
@~history_1251_li
#Two simple full text search implementations (Lucene and native) are now included. This is work in progress, and currently undocumented. See test/org/h2/samples/fullTextSearch.sql. To enable the Lucene implementation, you first need to install Lucene, rename FullTextLucene.java.txt to *.java and call 'ant compile'.
@~history_1252_li
#Two simple full text search implementations (Lucene and native) are now included. This is work in progress, and currently undocumented. See test/org/h2/samples/fullTextSearch.sql. To enable the Lucene implementation, you first need to install Lucene, rename FullTextLucene.java.txt to *.java and call 'ant compile'.
@~history_1266_h3
#Version 1.0 / 2006-10-10 (Build 28)
@~history_1272_h3
#Version 1.0 / 2006-10-10 (Build 28)
@~history_1272_li
#Reconnect didn't work after renaming a user if rights were granted for this user. Fixed.
@~history_1273_h3
#Version 1.0 / 2006-10-10 (Build 28)
@~history_1273_li
#Redundant () in a IN subquery is now supported: where id in ((select id from test))
@~history_1274_h3
#Version 1.0 / 2006-10-10 (Build 28)
@~history_1274_li
#Redundant () in a IN subquery is now supported: where id in ((select id from test))
@~history_1275_li
#Redundant () in a IN subquery is now supported: where id in ((select id from test))
@~history_1278_h3
#Version 1.0 / 2006-09-24 (Build 27)
@~history_1284_h3
#Version 1.0 / 2006-09-24 (Build 27)
@~history_1284_li
#Reading from compressed LOBs didn't work in some cases. Fixed.
@~history_1285_h3
#Version 1.0 / 2006-09-24 (Build 27)
@~history_1285_li
#New LOCK_MODE 3 (READ_COMMITTED). Table level locking, but only when writing (no read locks).
@~history_1286_h3
#Version 1.0 / 2006-09-24 (Build 27)
@~history_1286_li
#New LOCK_MODE 3 (READ_COMMITTED). Table level locking, but only when writing (no read locks).
@~history_1287_li
#New LOCK_MODE 3 (READ_COMMITTED). Table level locking, but only when writing (no read locks).
@~history_1303_h3
#Version 1.0 / 2006-09-10 (Build 26)
@~history_1309_h3
#Version 1.0 / 2006-09-10 (Build 26)
@~history_1309_li
#ROWNUM didn't always work as expected when using subqueries. This is fixed now. However, there is no standard definition for ROWNUM, for situations where you want to limit the number of rows (specially for offset), the standardized LIMIT [OFFSET] should be used
@~history_1310_h3
#Version 1.0 / 2006-09-10 (Build 26)
@~history_1310_li
#Updated the performance test so that Firebird can be tested as well.
@~history_1311_h3
#Version 1.0 / 2006-09-10 (Build 26)
@~history_1311_li
#Updated the performance test so that Firebird can be tested as well.
@~history_1312_li
#Updated the performance test so that Firebird can be tested as well.
@~history_1320_h3
#Version 1.0 / 2006-08-31 (Build 25)
@~history_1323_h3
#Version 0.9 / 2006-08-28
@~history_1326_h3
#Version 1.0 / 2006-08-31 (Build 25)
@~history_1326_li
#When large strings or byte arrays where inserted into a LOB (CLOB or BLOB), or if the data was stored using PreparedStatement.setBytes or setString, the data was stored in-place (no separate files where created). This is now implemented (that means distinct files are created in every case), however disabled by default. It is possible to enable this option with Constants.AUTO_CONVERT_LOB_TO_FILES = true
@~history_1327_h3
#Version 1.0 / 2006-08-31 (Build 25)
@~history_1327_li
#In some situations, wide b-tree indexes (with large VARCHAR columns for example) could get corrupted. Fixed.
@~history_1328_h3
#Version 1.0 / 2006-08-31 (Build 25)
@~history_1328_li
#In some situations, wide b-tree indexes (with large VARCHAR columns for example) could get corrupted. Fixed.
@~history_1329_h3
#Version 0.9 / 2006-08-28
@~history_1329_li
#Optimization for MIN and MAX (but currently disabled by default until after release 1.0): Queries such as SELECT MIN(ID), MAX(ID)+1, COUNT(*) FROM TEST now use an index if one is available. To enable manually, set Constants.OPTIMIZE_MIN_MAX = true in your application.
@~history_1330_h3
#Version 0.9 / 2006-08-28
@~history_1330_li
#DATEDIFF on seconds, minutes, hours did return different results in certain timezones (half-hour timezones) in certain situations. Fixed.
@~history_1331_h3
#Version 0.9 / 2006-08-28
@~history_1331_li
#DATEDIFF on seconds, minutes, hours did return different results in certain timezones (half-hour timezones) in certain situations. Fixed.
@~history_1332_li
#DATEDIFF on seconds, minutes, hours did return different results in certain timezones (half-hour timezones) in certain situations. Fixed.
@~history_1334_h3
#Version 0.9 / 2006-08-23 (Build 23)
@~history_1340_h3
#Version 0.9 / 2006-08-23 (Build 23)
@~history_1340_li
#Local temporary tables where not included in the meta data. Fixed.
@~history_1341_h3
#Version 0.9 / 2006-08-23 (Build 23)
@~history_1341_li
#Bugfix for LIKE: If collation was set (SET COLLATION ...), it was ignored when using LIKE. Fixed.
@~history_1342_h3
#Version 0.9 / 2006-08-23 (Build 23)
@~history_1342_li
#Bugfix for LIKE: If collation was set (SET COLLATION ...), it was ignored when using LIKE. Fixed.
@~history_1343_li
#Bugfix for LIKE: If collation was set (SET COLLATION ...), it was ignored when using LIKE. Fixed.
@~history_1345_h3
#Version 0.9 / 2006-08-14 (Build 21)
@~history_1351_h3
#Version 0.9 / 2006-08-14 (Build 21)
@~history_1351_li
#Umlauts and Chinese characters are now supported in identifier names (table name, column names and so on).
@~history_1352_h3
#Version 0.9 / 2006-08-14 (Build 21)
@~history_1352_li
#SET LOG 0 didn't work (except if the log level was set to some other value before). Fixed.
@~history_1353_h3
#Version 0.9 / 2006-08-14 (Build 21)
@~history_1353_li
#SET LOG 0 didn't work (except if the log level was set to some other value before). Fixed.
@~history_1354_li
#SET LOG 0 didn't work (except if the log level was set to some other value before). Fixed.
@~history_1355_h3
#Version 0.9 / 2006-07-29 (Build 18)
@~history_1361_h3
#Version 0.9 / 2006-07-29 (Build 18)
@~history_1361_li
#Shutdown TCP Server: The Server tool didn't throw / print a meaningful exception if the server was not running or if the password was wrong. Fixed.
@~history_1362_h3
#Version 0.9 / 2006-07-29 (Build 18)
@~history_1362_li
#ParameterMetaData is now implemented (mainly to support getParameterCount).
@~history_1363_h3
#Version 0.9 / 2006-07-29 (Build 18)
@~history_1363_li
#ParameterMetaData is now implemented (mainly to support getParameterCount).
@~history_1364_li
#ParameterMetaData is now implemented (mainly to support getParameterCount).
@~history_1374_h3
#Version 0.9 / 2005-12-13
@~history_1376_h2
#Roadmap
@~history_1377_h3
#Highest Priority
@~history_1380_h3
#Version 0.9 / 2005-12-13
@~history_1380_li
#Test very large databases and LOBs (up to 256 GB)
@~history_1381_h3
#Version 0.9 / 2005-12-13
@~history_1381_li
#First public release.
@~history_1382_h2
#Roadmap
@~history_1382_h3
#In Version 1.1
@~history_1382_li
#First public release.
@~history_1383_h2
#Roadmap
@~history_1383_h3
#Highest Priority
@~history_1383_li
#Add version number. Install directory: h2-1.0, jar file: h2-1.0.jar. Micro version: use build number, staring with 1.1.100
@~history_1384_h2
#Roadmap
@~history_1384_h3
#Highest Priority
@~history_1384_li
#Improve test code coverage
@~history_1385_h3
#Highest Priority
@~history_1385_li
#Improve test code coverage
@~history_1386_li
#Improve test code coverage
@~history_1388_h3
#In Version 1.1
@~history_1388_li
#Index organized tables CREATE TABLE...(...) ORGANIZATION INDEX (store in data file) (probably file format changes are required for rowId)
@~history_1389_h3
#In Version 1.1
@~history_1389_li
#Add version number. Install directory: h2-1.0, jar file: h2-1.0.jar. Micro version: use build number, staring with 1.1.100
@~history_1390_h3
#In Version 1.1
@~history_1390_li
#Add version number. Install directory: h2-1.0, jar file: h2-1.0.jar. Micro version: use build number, staring with 1.1.100
@~history_1391_h3
#Priority 1
@~history_1391_li
#Add version number. Install directory: h2-1.0, jar file: h2-1.0.jar. Micro version: use build number, staring with 1.1.100
@~history_1397_h3
#Priority 1
@~history_1397_li
#Document how to use H2 with PHP (generic database API)
@~history_1398_h3
#Priority 1
@~history_1398_li
#MVCC (Multi Version Concurrency Control)
@~history_1399_h3
#Priority 1
@~history_1399_li
#MVCC (Multi Version Concurrency Control)
@~history_1400_li
#MVCC (Multi Version Concurrency Control)
@~history_1422_h3
#Priority 2
@~history_1425_h3
#Priority 2
@~history_1425_li
#Change LOB mechanism (less files, keep index of lob files, point to files and row, delete unused files earlier, maybe bundle files into a tar file)
#Many thanks for those who helped by finding and reporting bugs, gave valuable feedback, spread the word and have translated this project. Also many thanks to the donors who contributed via PayPal:
@~history_1687_h3
#Not Planned
@~history_1689_h3
#Not Planned
@~history_1689_li
#String.intern (so that Strings can be compared with ==) will not be used because some VMs have problems when used extensively
@~history_1690_h2
#Supporters
@~history_1691_p
#Many thanks for those who helped by finding and reporting bugs, gave valuable feedback, spread the word and have translated this project. Also many thanks to the donors who contributed via PayPal:
@~history_1692_h2
#Supporters
@~history_1692_li
#Florent Ramiere, France
@~history_1693_h3
#Not Planned
@~history_1693_li
#Pete Haidinyak, USA
@~history_1693_p
#Many thanks for those who helped by finding and reporting bugs, gave valuable feedback, spread the word and have translated this project. Also many thanks to the donors who contributed via PayPal:
@~history_1694_h3
#Not Planned
@~history_1694_li
#HSQLDB (did) support this: select id i from test where i>0 (other databases don't)
@~history_1695_li
#HSQLDB (did) support this: select id i from test where i>0 (other databases don't)
@~history_1696_h2
#Supporters
@~history_1696_li
#Jun Iyama, Japan
@~history_1697_h2
#Supporters
@~history_1697_li
#Antonio Casqueiro, Portugal
@~history_1697_p
#Many thanks for those who helped by finding and reporting bugs, gave valuable feedback, spread the word and have translated this project. Also many thanks to the donors who contributed via PayPal:
@~history_1698_li
#Florent Ramiere, France
@~history_1698_p
#Many thanks for those who helped by finding and reporting bugs, gave valuable feedback, spread the word and have translated this project. Also many thanks to the donors who contributed via PayPal:
@~history_1699_li
#Florent Ramiere, France
@~mainWeb_1014_p
#Or send an e-mail to:
@~mainWeb_1015_td
#
@~mainWeb_1016_h3
#Performance
@~mainWeb_1017_td
#Operations/second (higher is better) - <a href="performance.html">More information about this test</a>
@~mainWeb_1019_h3
#News
@~mainWeb_1020_b
#Newsfeeds:
@~mainWeb_1021_p
#Two are available: <a href="http://www.h2database.com/html/newsfeed-atom.xml" target="_blank">Full text (Atom)</a> and <a href="http://www.h2database.com/html/newsfeed-rss.xml" target="_blank">Header only (RSS)</a> .
@~mainWeb_1022_b
#Email Newsletter:
@~mainWeb_1023_form
#Subscribe to <a href="http://groups.google.com/group/h2database-news/subscribe">H2 Database News (Google account required)</a> to get informed about new releases. Your email address is only used in this context. If you don't want a Google account, there is a manually maintained list as well:
@~mainWeb_1025_td
#
@~mainWeb_1026_h3
#Contribute
@~mainWeb_1027_p
#You can contribute to the development of H2 by sending feedback and bug reports, or translate the H2 Console application (files h2/src/main/org/h2/server/web/res/_text_*.properties). Or click on the PayPal button below to donate money. You will be listed as a supporter:
@~mainWeb_1028_td
#
@~mainWeb_1029_h3
#Feedback
@~mainWeb_1030_td
#You may also send questions, feature requests, or feedback of any kind here:
@~mainWeb_1031_p
#Email (optional):
@~mainWeb_1032_form
#Message:
@~~history_1329_li
#In some situations, wide b-tree indexes (with large VARCHAR columns for example) could get corrupted. Fixed.
#When using Java Web Start / JNLP (Java Network Launch Protocol), permissions tags must be set in the .jnlp file, and the application .jar file must be signed. Otherwise, when trying to write to the file system, the following exception will occur: java.security.AccessControlException: access denied (java.io.FilePermission ... read). Example permission tags:
@~faq_1010_h3
#Are there any known bugs? When is the next release?
@~faq_1011_p
#Usually, bugs get fixes as they are found. There is a release every few weeks. Here is the list of known and confirmed issues as of 2007-08-02:
@~faq_1012_li
#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.
@~faq_1013_h3
#Is this Database Engine Open Source?
@~faq_1014_p
#Yes. It is free to use and distribute, and the source code is included. See also under license.
@~faq_1015_h3
#My query is slow
@~faq_1016_p
#Slow SELECT (or DELETE, UPDATE, MERGE) statement can have multiple reasons. Follow this checklist:
@~faq_1017_li
#Run ANALYSE (see documentation for details).
@~faq_1021_h3
#How to Create a New Database?
@~faq_1022_p
#By default, a new database is automatically created if it does not yet exist.
@~faq_1023_h3
#How to Connect to a Database?
@~faq_1024_p
#The database driver is <code>org.h2.Driver</code> , and the database URL starts with <code>jdbc:h2:</code> . To connect to a database using JDBC, use the following code:
@~faq_1025_h3
#Where are the Database Files Stored?
@~faq_1026_p
#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 must exist. It is also possible to use the fully qualified directory (and for Windows, drive) name. Example: jdbc:h2:file:C:/data/test
@~faq_1027_h3
#What is the Size Limit (maximum size) of a Database?
@~faq_1028_p
#The theoretical limit is currently 256 GB for the data. This number is excluding BLOB and CLOB data: Every CLOB or BLOB can be up to 256 GB as well. The size limit of the index data is 256 GB as well.
@~faq_1030_h3
#Is it Reliable?
@~faq_1031_p
#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 as this is a relatively new product, there are probably some problems that have not yet been found. Areas that are not 100% tested:
@~faq_1032_li
#Platforms other than Windows XP and the Sun JVM 1.4 and 1.5
@~faq_1044_p
#Areas considered Experimental:
@~faq_1045_li
#ODBC driver and the GCJ native version on Windows
@~faq_1049_h3
#Is the GCJ version stable? Faster?
@~faq_1050_p
#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.
@~features_1202_h2
#Connection Modes
@~features_1203_p
#The following connection modes are supported:
@~features_1204_li
#Local connections using JDBC (embedded)
@~features_1205_li
#Remote connections using JDBC over TCP/IP (client/server)
@~features_1208_h2
#Database URL Overview
@~features_1209_p
#This database does support multiple connection modes and features when connecting to a database. This is achieved using different database URLs. The settings in the URLs are not case sensitive.
#The database URL for connecting to a local database is <code>jdbc:h2:[file:][<path>]<databaseName></code> . The prefix <code>file:</code> is optional. If no or only a relative path is used, then the current working directory is used as a starting point. The case sensitivity of the path and database name depend on the operating system, however it is suggested to use lowercase letters only. The database name must be at least three characters long (a limitation of File.createTempFile). To point to the user home directory, use ~/, as in: jdbc:h2:~/test.
@~features_1262_p
#In some cases, only one connection to a memory-only database is required. This means the database to be opened is private. In this case, the database URL is <code>jdbc:h2:mem:</code> Opening two connections within the same virtual machine means opening two different (private) databases.
@~features_1265_h2
#Connecting to a Database with File Encryption
@~features_1269_p
#The following file locking methods are implemented:
@~features_1270_li
#The default method is 'file' and uses a watchdog thread to protect the database file. The watchdog reads the lock file each second.
@~features_1271_li
#The second method is 'socket' and opens a server socket. The socket method does not require reading the lock file every second. The socket method should only be used if the database files are only accessed by the one (and always the same) computer.
@~features_1273_p
#To open the database with a different file locking method, use the parameter 'FILE_LOCK'. The following code opens the database with the 'socket' locking method:
@~features_1274_p
#The following code forces the database to not create a lock file at all. Please note that this is unsafe as another process is able to open the same database, possibly leading to data corruption:
@~features_1276_h2
#Opening a Database Only if it Already Exists
@~features_1279_h3
#Delayed Database Closing
@~features_1280_p
#Usually, the database is closed when the last connection to it is closed. In some situations this slows down the application, for example when it is not possible leave the connection open. The automatic closing of the database can be delayed or disabled with the SQL statement SET DB_CLOSE_DELAY <seconds>. The seconds specifies the number of seconds to keep a database open after the last connection to it was closed. For example the following statement will keep the database open for 10 seconds:
@~features_1281_p
#The value -1 means the database is never closed automatically. The value 0 is the default and means the database is closed when the last connection is closed. This setting is persistent and can be set by an administrator only. It is possible to set the value in the database URL: <code>jdbc:h2:~/test;DB_CLOSE_DELAY=10</code> .
@~features_1282_h3
#Don't Close the Database when the VM Exits
@~features_1284_h2
#Log Index Changes
@~features_1286_h3
#Ignore Unknown Settings
@~features_1290_h2
#Custom File Access Mode
@~features_1292_p
#For more information see <a href="advanced.html#durability_problems">Durability Problems</a> . On many operating systems the access mode 'rws' does not guarantee that the data is written to the disk.
@~features_1293_h2
#Multiple Connections
@~features_1294_h3
#Opening Multiple Databases at the Same Time
@~features_1295_p
#An application can open multiple databases at the same time, including multiple connections to the same database. The number of open database is only limited by the memory available.
@~features_1302_p
#Usually, SELECT statement will generate read locks. This includes subqueries. Statements that modify data use write locks. It is also possible to lock a table exclusively without modifying data, using the statement SELECT ... FOR UPDATE. The statements COMMIT and ROLLBACK releases all open locks. The commands SAVEPOINT and ROLLBACK TO SAVEPOINT don't affect locks. The locks are also released when the autocommit mode changes, and for connections with autocommit set to true (this is the default), locks are released after each statement. Here is an overview on what statements generate what type of lock:
@~features_1303_th
#Type of Lock
@~features_1304_th
#SQL Statement
@~features_1305_td
#Read
@~features_1306_td
#SELECT * FROM TEST
@~features_1320_p
#The number of seconds until a lock timeout exception is thrown can be set separately for each connection using the SQL command SET LOCK_TIMEOUT <milliseconds>. The initial lock timeout (that is the timeout used for new connections) can be set using the SQL command SET DEFAULT_LOCK_TIMEOUT <milliseconds>. The default lock timeout is persistent.
@~features_1321_h2
#Database File Layout
@~features_1323_th
#File Name
@~features_1324_th
#Description
@~features_1326_td
#test.data.db
@~features_1327_td
#Data file
@~features_1367_h3
#Moving and Renaming Database Files
@~features_1368_p
#Database name and location are not stored inside the database names.
@~features_1369_p
#While a database is closed, the files can be moved to another directory, and they can be renamed as well (as long as all files start with the same name).
@~features_1371_h3
#Backup
@~features_1373_p
#To backup data while the database is running, the SQL command SCRIPT can be used.
@~features_1374_h2
#Logging and Recovery
@~features_1376_p
#Please note that index file updates are not logged by default. If the database is opened and recovery is required, the index file is rebuilt from scratch.
@~features_1379_h2
#Compatibility Modes
@~features_1381_th
#Mode
@~features_1382_th
#Differences
@~features_1383_td
#PostgreSQL
@~features_1384_td
#Concatenation of a NULL with another value results in NULL. Usually, the NULL is treated as an empty string if only one of the operators is NULL, and NULL is only returned if both values are NULL.
@~features_1389_h2
#Using the Trace Options
@~features_1390_p
#To find problems in an application, it is sometimes good to see what database operations where executed. This database offers the following trace features:
@~features_1391_li
#Trace to System.out and/or a file
@~features_1392_li
#Support for trace levels OFF, ERROR, INFO, and DEBUG
@~features_1396_h3
#Trace Options
@~features_1397_p
#The simplest way to enable the trace option is setting it in the database URL. There are two settings, one for System.out (TRACE_LEVEL_SYSTEM_OUT) tracing, and one for file tracing (TRACE_LEVEL_FILE). The trace levels are 0 for OFF, 1 for ERROR (the default), 2 for INFO and 3 for DEBUG. A database URL with both levels set to DEBUG is:
@~features_1398_p
#The trace level can be changed at runtime by executing the SQL command <code>SET TRACE_LEVEL_SYSTEM_OUT level</code> (for System.out tracing) or <code>SET TRACE_LEVEL_FILE level</code> (for file tracing). Example:
@~features_1399_h3
#Setting the Maximum Size of the Trace File
@~features_1403_p
#You need to filter out the lines without /**/ to get the Java source code. In Windows, a simple way to do that is:
@~features_1406_h3
#Enabling the Trace Option at Runtime by Manually Creating a File
@~features_1408_p
#Example: if a database is called 'test', then the file to start tracing is 'test.trace.db.start'. The database engine tries to delete this file when it detects it. If trace is enabled using the start file, the trace level is not persistent to the database, and trace is switched back to the level that was set before when connecting to the database. However, if the start file is read only, the database engine cannot delete the file and will always enable the trace mode when connecting.
@~features_1409_h2
#Read Only Databases
@~features_1415_p
#It is possible to install a database event listener to detect low disk space situations early on (when only 1 MB if space is available). To do this, use the SQL statement SET DATABASE_EVENT_LISTENER. The listener can also be set at connection time, using an URL of the form jdbc:h2:~/test;DATABASE_EVENT_LISTENER='com.acme.DbListener' (the quotes around the class name are required). See also the DatabaseEventListener API.
@~features_1416_h3
#Opening a Corrupted Database
@~features_1418_h2
#Computed Columns / Function Based Index
@~features_1420_p
#When inserting data, it is not required (better: not allowed) to specify a value for the upper-case version of the column, because the value is generated. But you can use the column when querying the table:
@~features_1421_h2
#Multi-Dimensional Indexes
@~features_1423_p
#Currently, Z-order (also called N-order or Morton-order) is used; Hilbert curve could also be used, but the implementation is more complex. The algorithm to convert the multi-dimensional value is called bit-interleaving. The scalar value is indexed using a B-Tree index (usually using a computed column).
@~features_1425_h2
#Using Passwords
@~features_1426_h3
#Using Secure Passwords
@~features_1427_p
#Remember that weak passwords can be broken no matter of the encryption and security protocol. Don't use passwords that can be found in a dictionary. Also appending numbers does not make them secure. A way to create good passwords that can be remembered is, take the first letters of a sentence, use upper and lower case characters, and creatively include special characters. Example:
@~features_1428_p
#i'sE2rtPiUKtT (it's easy to remember this password if you know the trick)
@~features_1429_h3
#Passwords: Using Char Arrays instead of Strings
@~features_1431_p
#An attacker might have access to the swap file of the operating system. It is therefore a good idea to use char arrays instead of Strings to store passwords. Char arrays can be cleared (filled with zeros) after use, and therefore the password will not be stored in the swap file.
@~features_1434_h3
#Passing the User Name and/or Password in the URL
@~features_1436_h2
#User Defined Functions and Stored Procedures
@~features_1438_p
#The Java function must be registered in the database by calling CREATE ALIAS:
@~features_1440_h3
#Function Data Type Mapping
@~features_1452_h2
#Triggers
@~features_1454_p
#The connection can be used to query or update data in other tables. The trigger then needs to be defined in the database:
@~features_1456_h2
#Compacting a Database
@~features_1458_p
#See also the sample application org.h2.samples.Compact. The commands SCRIPT / RUNSCRIPT can be used as well to create the a backup of a database and re-build the database from the script.
@~features_1459_h2
#Cache Settings
@~features_1461_p
#This database supports two cache page replacement algorithms: LRU (the default) and 2Q. For LRU, the pages that were least frequently used are removed from the cache if it becomes full. The 2Q algorithm is a bit more complicated, basically two queues are used. The 2Q algorithm is more resistant to table scans, however the overhead is a bit higher compared to the LRU. To use the cache algorithm 2Q, use a database URL of the form jdbc:h2:~/test;CACHE_TYPE=TQ. The cache algorithm can not be changed once the database is open.
@~features_1463_h2
#Why Java
@~features_1465_li
#Very simple to integrate in Java applications
@~features_1466_li
#Support for many different platforms
@~features_1470_p
#Some people think that Java is still too slow for low level operations, but this is not the case (not any more). In general, the code can be written a lot faster than using C or C++. Like that, it is possible to concentrate on improving the algorithms (that make the application faster) rather than porting the code and dealing with low level stuff (such as memory management or dealing with threads). Garbage collection is now probably faster than manual memory management.
@~features_1471_p
#A lot of features are already built in (for example Unicode, network libraries). It is very easy to write secure code because buffer overflows and such problems can be detected very easily. Some features such as the reflection mechanism can be used for randomized testing.
@~history_1023_h3
#Version 1.0 / 2007-08-02 (Build 56)
@~history_1029_h3
#Version 1.0 / 2007-08-02 (Build 56)
@~history_1029_li
#A server that implements the PostgreSQL protocol is now included and documented. That means, the PostgreSQL ODBC driver can be used to access a H2 database. See in the documentation for details.
@~history_1030_h3
#Version 1.0 / 2007-08-02 (Build 56)
@~history_1030_li
#A new tool to help translation has been implemented: src/tools/org/h2/tools/i18n/PrepareTranslation. This tool can detect delta changes in the original (English) and prepends '#' in translation if the original text was changed. It can also extract text from the user documentation (however, it is incomplete).
@~history_1031_h3
#Version 1.0 / 2007-08-02 (Build 56)
@~history_1031_li
#A new tool to help translation has been implemented: src/tools/org/h2/tools/i18n/PrepareTranslation. This tool can detect delta changes in the original (English) and prepends '#' in translation if the original text was changed. It can also extract text from the user documentation (however, it is incomplete).
@~history_1032_li
#A new tool to help translation has been implemented: src/tools/org/h2/tools/i18n/PrepareTranslation. This tool can detect delta changes in the original (English) and prepends '#' in translation if the original text was changed. It can also extract text from the user documentation (however, it is incomplete).
@~history_1050_h3
#Version 1.0 / 2007-07-12 (Build 55)
@~history_1056_h3
#Version 1.0 / 2007-07-12 (Build 55)
@~history_1056_li
#New column ID for INFORMATION_SCHEMA.INDEXES, SEQUENCES, USERS, ROLES, RIGHTS, FUNCTION_ALIASES, SCHEMATA, VIEWS, CONSTRAINTS, CONSTANTS, DOMAINS, TRIGGERS.
@~history_1057_h3
#Version 1.0 / 2007-07-12 (Build 55)
@~history_1057_li
#Support for the system property baseDir. This works for embedded databases as well. The setting is supported by the H2 Console using -Dh2.baseDir or -baseDir
@~history_1058_h3
#Version 1.0 / 2007-07-12 (Build 55)
@~history_1058_li
#Support for the system property baseDir. This works for embedded databases as well. The setting is supported by the H2 Console using -Dh2.baseDir or -baseDir
@~history_1059_li
#Support for the system property baseDir. This works for embedded databases as well. The setting is supported by the H2 Console using -Dh2.baseDir or -baseDir
@~history_1076_h3
#Version 1.0 / 2007-06-17 (Build 50)
@~history_1082_h3
#Version 1.0 / 2007-06-17 (Build 50)
@~history_1082_li
#Views support has been partially re-implemented. Views are up to 6 times faster. Compared to regular queries, only 20% overhead. Because this is a bigger change, it is not enabled by default. To enable it, set the system property 'h2.indexNew' to true (java -Dh2.indexNew=true ..., or in source code Constants.INDEX_NEW = true). If no problems are found, this will be enabled by default in the next release.
@~history_1083_h3
#Version 1.0 / 2007-06-17 (Build 50)
@~history_1083_li
#File names starting with ~ are now in the user directory (Java system property user.home)
@~history_1084_h3
#Version 1.0 / 2007-06-17 (Build 50)
@~history_1084_li
#File names starting with ~ are now in the user directory (Java system property user.home)
@~history_1085_li
#File names starting with ~ are now in the user directory (Java system property user.home)
@~history_1101_h3
#Version 1.0 / 2007-04-29 (Build 46)
@~history_1107_h3
#Version 1.0 / 2007-04-29 (Build 46)
@~history_1107_li
#SimpleResultSet now has some basic data type conversion features.
@~history_1108_h3
#Version 1.0 / 2007-04-29 (Build 46)
@~history_1108_li
#Unnamed private in-memory database (jdbc:h2:mem:) were not 'private' as documented. Fixed.
@~history_1109_h3
#Version 1.0 / 2007-04-29 (Build 46)
@~history_1109_li
#Unnamed private in-memory database (jdbc:h2:mem:) were not 'private' as documented. Fixed.
@~history_1110_li
#Unnamed private in-memory database (jdbc:h2:mem:) were not 'private' as documented. Fixed.
@~history_1135_h3
#Version 1.0 / 2007-03-04 (Build 44)
@~history_1141_h3
#Version 1.0 / 2007-03-04 (Build 44)
@~history_1141_li
#After renaming a user the password becomes invalid. This is now documented.
@~history_1142_h3
#Version 1.0 / 2007-03-04 (Build 44)
@~history_1142_li
#System sequences (automatically created sequences for IDENTITY or AUTO_INCREMENT columns) are now random (UUIDs) to avoid clashes when merging databases using RUNSCRIPT.
@~history_1143_h3
#Version 1.0 / 2007-03-04 (Build 44)
@~history_1143_li
#System sequences (automatically created sequences for IDENTITY or AUTO_INCREMENT columns) are now random (UUIDs) to avoid clashes when merging databases using RUNSCRIPT.
@~history_1144_li
#System sequences (automatically created sequences for IDENTITY or AUTO_INCREMENT columns) are now random (UUIDs) to avoid clashes when merging databases using RUNSCRIPT.
@~history_1152_h3
#Version 1.0 / 2007-01-30 (Build 41)
@~history_1158_h3
#Version 1.0 / 2007-01-30 (Build 41)
@~history_1158_li
#The Console is now translated to Hungarian thanks to Andras Hideg, and to Indonesian thanks to Joko Yuliantoro
@~history_1159_h3
#Version 1.0 / 2007-01-30 (Build 41)
@~history_1159_li
#Experimental online backup feature using the SQL statement BACKUP TO 'fileName'. This creates a backup in the form of a zip file. Unlike the SCRIPT TO command, the data tables are not locked.
@~history_1160_h3
#Version 1.0 / 2007-01-30 (Build 41)
@~history_1160_li
#Experimental online backup feature using the SQL statement BACKUP TO 'fileName'. This creates a backup in the form of a zip file. Unlike the SCRIPT TO command, the data tables are not locked.
@~history_1161_li
#Experimental online backup feature using the SQL statement BACKUP TO 'fileName'. This creates a backup in the form of a zip file. Unlike the SCRIPT TO command, the data tables are not locked.
@~history_1167_h3
#Version 1.0 / 2007-01-17 (Build 40)
@~history_1173_h3
#Version 1.0 / 2007-01-17 (Build 40)
@~history_1173_li
#Selecting a column using the syntax schemaName.tableName.columnName did not work in all cases.
@~history_1174_h3
#Version 1.0 / 2007-01-17 (Build 40)
@~history_1174_li
#Setting the collation (SET COLLATOR) was very slow on some systems (up to 24 seconds). Thanks a lot to Martina Nissler for finding this problem!
@~history_1175_h3
#Version 1.0 / 2007-01-17 (Build 40)
@~history_1175_li
#Setting the collation (SET COLLATOR) was very slow on some systems (up to 24 seconds). Thanks a lot to Martina Nissler for finding this problem!
@~history_1176_li
#Setting the collation (SET COLLATOR) was very slow on some systems (up to 24 seconds). Thanks a lot to Martina Nissler for finding this problem!
@~history_1179_h3
#Version 1.0 / 2007-01-02 (Build 36)
@~history_1185_h3
#Version 1.0 / 2007-01-02 (Build 36)
@~history_1185_li
#Using ;RECOVER=1 in the database URL threw a syntax exception. Fixed.
@~history_1186_h3
#Version 1.0 / 2007-01-02 (Build 36)
@~history_1186_li
#It was possible to drop the sequence of a temporary tables with DROP ALL OBJECTS, resulting in a null pointer exception afterwards.
@~history_1187_h3
#Version 1.0 / 2007-01-02 (Build 36)
@~history_1187_li
#It was possible to drop the sequence of a temporary tables with DROP ALL OBJECTS, resulting in a null pointer exception afterwards.
@~history_1188_li
#It was possible to drop the sequence of a temporary tables with DROP ALL OBJECTS, resulting in a null pointer exception afterwards.
@~history_1191_h3
#Version 1.0 / 2006-12-17 (Build 34)
@~history_1197_h3
#Version 1.0 / 2006-12-17 (Build 34)
@~history_1197_li
#The RunScript tool can now include other files using a new syntax: @INCLUDE fileName. It was already possible to do that using embedded RUNSCRIPT statements, but not remotely.
@~history_1198_h3
#Version 1.0 / 2006-12-17 (Build 34)
@~history_1198_li
#Can be compiled with JDK 1.6. However, only very few of the JDBC 4.0 features are implemented so far.
@~history_1199_h3
#Version 1.0 / 2006-12-17 (Build 34)
@~history_1199_li
#Can be compiled with JDK 1.6. However, only very few of the JDBC 4.0 features are implemented so far.
@~history_1200_li
#Can be compiled with JDK 1.6. However, only very few of the JDBC 4.0 features are implemented so far.
@~history_1206_h3
#Version 1.0 / 2006-12-03 (Build 32)
@~history_1212_h3
#Version 1.0 / 2006-12-03 (Build 32)
@~history_1212_li
#There was a bug in the database encryption algorithm. The initialization vector was not correctly calculated, and pattern of repeated encrypted bytes where generated for empty blocks in the file. This has been is fixed. The security of the data itself was not compromised, but this was not the intended behavior. If you have an encrypted database, you will need to decrypt the database using the org.h2.tools.ChangePassword (using the old database engine), and encrypt the database using the new engine. Alternatively, you can use the Backup and RunScript tools or the SQL commands SCRIPT and RUNSCRIPT.
@~history_1213_h3
#Version 1.0 / 2006-12-03 (Build 32)
@~history_1213_li
#The SQL statement COMMENT did not work as expected. Many bugs have been fixed in this area. If you already have comments in the database, it is recommended to backup and restore the database, using the Backup and RunScript tools or the SQL commands SCRIPT and RUNSCRIPT.
@~history_1214_h3
#Version 1.0 / 2006-12-03 (Build 32)
@~history_1214_li
#The SQL statement COMMENT did not work as expected. Many bugs have been fixed in this area. If you already have comments in the database, it is recommended to backup and restore the database, using the Backup and RunScript tools or the SQL commands SCRIPT and RUNSCRIPT.
@~history_1215_li
#The SQL statement COMMENT did not work as expected. Many bugs have been fixed in this area. If you already have comments in the database, it is recommended to backup and restore the database, using the Backup and RunScript tools or the SQL commands SCRIPT and RUNSCRIPT.
@~history_1219_h3
#Version 1.0 / 2006-11-20 (Build 31)
@~history_1225_h3
#Version 1.0 / 2006-11-20 (Build 31)
@~history_1225_li
#Direct links to the Javadoc were not working.
@~history_1226_h3
#Version 1.0 / 2006-11-20 (Build 31)
@~history_1226_li
#SCRIPT: New option BLOCKSIZE to split BLOB and CLOB data into separate blocks, to avoid OutOfMemory problems.
@~history_1227_h3
#Version 1.0 / 2006-11-20 (Build 31)
@~history_1227_li
#SCRIPT: New option BLOCKSIZE to split BLOB and CLOB data into separate blocks, to avoid OutOfMemory problems.
@~history_1228_li
#SCRIPT: New option BLOCKSIZE to split BLOB and CLOB data into separate blocks, to avoid OutOfMemory problems.
@~history_1243_h3
#Version 1.0 / 2006-11-03 (Build 30)
@~history_1249_h3
#Version 1.0 / 2006-11-03 (Build 30)
@~history_1249_li
#Linked Tables: Only the first column was linked when linking to PostgreSQL, or a subquery. Fixed.
@~history_1250_h3
#Version 1.0 / 2006-11-03 (Build 30)
@~history_1250_li
#Two simple full text search implementations (Lucene and native) are now included. This is work in progress, and currently undocumented. See test/org/h2/samples/fullTextSearch.sql. To enable the Lucene implementation, you first need to install Lucene, rename FullTextLucene.java.txt to *.java and call 'ant compile'.
@~history_1251_h3
#Version 1.0 / 2006-11-03 (Build 30)
@~history_1251_li
#Two simple full text search implementations (Lucene and native) are now included. This is work in progress, and currently undocumented. See test/org/h2/samples/fullTextSearch.sql. To enable the Lucene implementation, you first need to install Lucene, rename FullTextLucene.java.txt to *.java and call 'ant compile'.
@~history_1252_li
#Two simple full text search implementations (Lucene and native) are now included. This is work in progress, and currently undocumented. See test/org/h2/samples/fullTextSearch.sql. To enable the Lucene implementation, you first need to install Lucene, rename FullTextLucene.java.txt to *.java and call 'ant compile'.
@~history_1266_h3
#Version 1.0 / 2006-10-10 (Build 28)
@~history_1272_h3
#Version 1.0 / 2006-10-10 (Build 28)
@~history_1272_li
#Reconnect didn't work after renaming a user if rights were granted for this user. Fixed.
@~history_1273_h3
#Version 1.0 / 2006-10-10 (Build 28)
@~history_1273_li
#Redundant () in a IN subquery is now supported: where id in ((select id from test))
@~history_1274_h3
#Version 1.0 / 2006-10-10 (Build 28)
@~history_1274_li
#Redundant () in a IN subquery is now supported: where id in ((select id from test))
@~history_1275_li
#Redundant () in a IN subquery is now supported: where id in ((select id from test))
@~history_1278_h3
#Version 1.0 / 2006-09-24 (Build 27)
@~history_1284_h3
#Version 1.0 / 2006-09-24 (Build 27)
@~history_1284_li
#Reading from compressed LOBs didn't work in some cases. Fixed.
@~history_1285_h3
#Version 1.0 / 2006-09-24 (Build 27)
@~history_1285_li
#New LOCK_MODE 3 (READ_COMMITTED). Table level locking, but only when writing (no read locks).
@~history_1286_h3
#Version 1.0 / 2006-09-24 (Build 27)
@~history_1286_li
#New LOCK_MODE 3 (READ_COMMITTED). Table level locking, but only when writing (no read locks).
@~history_1287_li
#New LOCK_MODE 3 (READ_COMMITTED). Table level locking, but only when writing (no read locks).
@~history_1303_h3
#Version 1.0 / 2006-09-10 (Build 26)
@~history_1309_h3
#Version 1.0 / 2006-09-10 (Build 26)
@~history_1309_li
#ROWNUM didn't always work as expected when using subqueries. This is fixed now. However, there is no standard definition for ROWNUM, for situations where you want to limit the number of rows (specially for offset), the standardized LIMIT [OFFSET] should be used
@~history_1310_h3
#Version 1.0 / 2006-09-10 (Build 26)
@~history_1310_li
#Updated the performance test so that Firebird can be tested as well.
@~history_1311_h3
#Version 1.0 / 2006-09-10 (Build 26)
@~history_1311_li
#Updated the performance test so that Firebird can be tested as well.
@~history_1312_li
#Updated the performance test so that Firebird can be tested as well.
@~history_1320_h3
#Version 1.0 / 2006-08-31 (Build 25)
@~history_1323_h3
#Version 0.9 / 2006-08-28
@~history_1326_h3
#Version 1.0 / 2006-08-31 (Build 25)
@~history_1326_li
#When large strings or byte arrays where inserted into a LOB (CLOB or BLOB), or if the data was stored using PreparedStatement.setBytes or setString, the data was stored in-place (no separate files where created). This is now implemented (that means distinct files are created in every case), however disabled by default. It is possible to enable this option with Constants.AUTO_CONVERT_LOB_TO_FILES = true
@~history_1327_h3
#Version 1.0 / 2006-08-31 (Build 25)
@~history_1327_li
#In some situations, wide b-tree indexes (with large VARCHAR columns for example) could get corrupted. Fixed.
@~history_1328_h3
#Version 1.0 / 2006-08-31 (Build 25)
@~history_1328_li
#In some situations, wide b-tree indexes (with large VARCHAR columns for example) could get corrupted. Fixed.
@~history_1329_h3
#Version 0.9 / 2006-08-28
@~history_1329_li
#Optimization for MIN and MAX (but currently disabled by default until after release 1.0): Queries such as SELECT MIN(ID), MAX(ID)+1, COUNT(*) FROM TEST now use an index if one is available. To enable manually, set Constants.OPTIMIZE_MIN_MAX = true in your application.
@~history_1330_h3
#Version 0.9 / 2006-08-28
@~history_1330_li
#DATEDIFF on seconds, minutes, hours did return different results in certain timezones (half-hour timezones) in certain situations. Fixed.
@~history_1331_h3
#Version 0.9 / 2006-08-28
@~history_1331_li
#DATEDIFF on seconds, minutes, hours did return different results in certain timezones (half-hour timezones) in certain situations. Fixed.
@~history_1332_li
#DATEDIFF on seconds, minutes, hours did return different results in certain timezones (half-hour timezones) in certain situations. Fixed.
@~history_1334_h3
#Version 0.9 / 2006-08-23 (Build 23)
@~history_1340_h3
#Version 0.9 / 2006-08-23 (Build 23)
@~history_1340_li
#Local temporary tables where not included in the meta data. Fixed.
@~history_1341_h3
#Version 0.9 / 2006-08-23 (Build 23)
@~history_1341_li
#Bugfix for LIKE: If collation was set (SET COLLATION ...), it was ignored when using LIKE. Fixed.
@~history_1342_h3
#Version 0.9 / 2006-08-23 (Build 23)
@~history_1342_li
#Bugfix for LIKE: If collation was set (SET COLLATION ...), it was ignored when using LIKE. Fixed.
@~history_1343_li
#Bugfix for LIKE: If collation was set (SET COLLATION ...), it was ignored when using LIKE. Fixed.
@~history_1345_h3
#Version 0.9 / 2006-08-14 (Build 21)
@~history_1351_h3
#Version 0.9 / 2006-08-14 (Build 21)
@~history_1351_li
#Umlauts and Chinese characters are now supported in identifier names (table name, column names and so on).
@~history_1352_h3
#Version 0.9 / 2006-08-14 (Build 21)
@~history_1352_li
#SET LOG 0 didn't work (except if the log level was set to some other value before). Fixed.
@~history_1353_h3
#Version 0.9 / 2006-08-14 (Build 21)
@~history_1353_li
#SET LOG 0 didn't work (except if the log level was set to some other value before). Fixed.
@~history_1354_li
#SET LOG 0 didn't work (except if the log level was set to some other value before). Fixed.
@~history_1355_h3
#Version 0.9 / 2006-07-29 (Build 18)
@~history_1361_h3
#Version 0.9 / 2006-07-29 (Build 18)
@~history_1361_li
#Shutdown TCP Server: The Server tool didn't throw / print a meaningful exception if the server was not running or if the password was wrong. Fixed.
@~history_1362_h3
#Version 0.9 / 2006-07-29 (Build 18)
@~history_1362_li
#ParameterMetaData is now implemented (mainly to support getParameterCount).
@~history_1363_h3
#Version 0.9 / 2006-07-29 (Build 18)
@~history_1363_li
#ParameterMetaData is now implemented (mainly to support getParameterCount).
@~history_1364_li
#ParameterMetaData is now implemented (mainly to support getParameterCount).
@~history_1374_h3
#Version 0.9 / 2005-12-13
@~history_1376_h2
#Roadmap
@~history_1377_h3
#Highest Priority
@~history_1380_h3
#Version 0.9 / 2005-12-13
@~history_1380_li
#Test very large databases and LOBs (up to 256 GB)
@~history_1381_h3
#Version 0.9 / 2005-12-13
@~history_1381_li
#First public release.
@~history_1382_h2
#Roadmap
@~history_1382_h3
#In Version 1.1
@~history_1382_li
#First public release.
@~history_1383_h2
#Roadmap
@~history_1383_h3
#Highest Priority
@~history_1383_li
#Add version number. Install directory: h2-1.0, jar file: h2-1.0.jar. Micro version: use build number, staring with 1.1.100
@~history_1384_h2
#Roadmap
@~history_1384_h3
#Highest Priority
@~history_1384_li
#Improve test code coverage
@~history_1385_h3
#Highest Priority
@~history_1385_li
#Improve test code coverage
@~history_1386_li
#Improve test code coverage
@~history_1388_h3
#In Version 1.1
@~history_1388_li
#Index organized tables CREATE TABLE...(...) ORGANIZATION INDEX (store in data file) (probably file format changes are required for rowId)
@~history_1389_h3
#In Version 1.1
@~history_1389_li
#Add version number. Install directory: h2-1.0, jar file: h2-1.0.jar. Micro version: use build number, staring with 1.1.100
@~history_1390_h3
#In Version 1.1
@~history_1390_li
#Add version number. Install directory: h2-1.0, jar file: h2-1.0.jar. Micro version: use build number, staring with 1.1.100
@~history_1391_h3
#Priority 1
@~history_1391_li
#Add version number. Install directory: h2-1.0, jar file: h2-1.0.jar. Micro version: use build number, staring with 1.1.100
@~history_1397_h3
#Priority 1
@~history_1397_li
#Document how to use H2 with PHP (generic database API)
@~history_1398_h3
#Priority 1
@~history_1398_li
#MVCC (Multi Version Concurrency Control)
@~history_1399_h3
#Priority 1
@~history_1399_li
#MVCC (Multi Version Concurrency Control)
@~history_1400_li
#MVCC (Multi Version Concurrency Control)
@~history_1422_h3
#Priority 2
@~history_1425_h3
#Priority 2
@~history_1425_li
#Change LOB mechanism (less files, keep index of lob files, point to files and row, delete unused files earlier, maybe bundle files into a tar file)
#Many thanks for those who helped by finding and reporting bugs, gave valuable feedback, spread the word and have translated this project. Also many thanks to the donors who contributed via PayPal:
@~history_1687_h3
#Not Planned
@~history_1689_h3
#Not Planned
@~history_1689_li
#String.intern (so that Strings can be compared with ==) will not be used because some VMs have problems when used extensively
@~history_1690_h2
#Supporters
@~history_1691_p
#Many thanks for those who helped by finding and reporting bugs, gave valuable feedback, spread the word and have translated this project. Also many thanks to the donors who contributed via PayPal:
@~history_1692_h2
#Supporters
@~history_1692_li
#Florent Ramiere, France
@~history_1693_h3
#Not Planned
@~history_1693_li
#Pete Haidinyak, USA
@~history_1693_p
#Many thanks for those who helped by finding and reporting bugs, gave valuable feedback, spread the word and have translated this project. Also many thanks to the donors who contributed via PayPal:
@~history_1694_h3
#Not Planned
@~history_1694_li
#HSQLDB (did) support this: select id i from test where i>0 (other databases don't)
@~history_1695_li
#HSQLDB (did) support this: select id i from test where i>0 (other databases don't)
@~history_1696_h2
#Supporters
@~history_1696_li
#Jun Iyama, Japan
@~history_1697_h2
#Supporters
@~history_1697_li
#Antonio Casqueiro, Portugal
@~history_1697_p
#Many thanks for those who helped by finding and reporting bugs, gave valuable feedback, spread the word and have translated this project. Also many thanks to the donors who contributed via PayPal:
@~history_1698_li
#Florent Ramiere, France
@~history_1698_p
#Many thanks for those who helped by finding and reporting bugs, gave valuable feedback, spread the word and have translated this project. Also many thanks to the donors who contributed via PayPal:
