Java Doc for jdbcConnection.java in  » Database-DBMS » hsql » org » hsqldb » jdbc » Java Source Code / Java DocumentationJava Source Code and Java Documentation

---

HSQLDB-Specific Information:

To get a Connection to an HSQLDB database, the following code may be used (updated to reflect the most recent recommendations):

---

When using HSQLDB, the database connection <url> must start with 'jdbc:hsqldb:'

Since 1.7.2, connection properties (<key-value-pairs>) may be appended to the database connection <url>, using the form:

'<url>[;key=value]*'

Also since 1.7.2, the allowable forms of the HSQLDB database connection <url> have been extended. However, all legacy forms continue to work, with unchanged semantics. The extensions are as described in the following material.

---

Network Server Database Connections:

The 1.7.2 Server Server database connection <url> has changed to take one of the two following forms:

The 1.7.2 WebServer WebServer database connection <url> also changes to take one of two following forms:

In both network server database connection <url> forms, the optional <alias> component is used to identify one of possibly several database instances available at the indicated host and port. If the <alias> component is omitted, then a connection is made to the network server's default database instance.

For more information on server configuration regarding mounting multiple databases and assigning them <alias> values, please read the Java API documentation for org.hsqldb.Server Server and related chapters in the general documentation, especially the Advanced Users Guide.

---

Transient, In-Process Database Connections:

The 1.7.2 100% in-memory (transient, in-process) database connection <url> takes one of the two following forms:

With the 1.7.2 transient, in-process database connection <url>, the <alias> component is the key used to look up a transient, in-process database instance amongst the collection of all such instances already in existence within the current class loading context in the current JVM. If no such instance exists, one may be automatically created and mapped to the <alias>, as governed by the 'ifexists=true|false' connection property.

---

Persistent, In-Process Database Connections:

The 1.7.2 standalone (persistent, in-process) database connection <url> takes one of the three following forms:

For the persistent, in-process database connection <url>, the <path> component is the path prefix common to all of the files that compose the database.

As of 1.7.2, although other files may be involved (such as transient working files and/or TEXT table CSV data source files), the essential set that may, at any particular point in time, compose an HSQLDB database are:

For example: 'jdbc:hsqldb:file:test' connects to a database composed of some subset of the files listed above, where the expansion of <path> is 'test' prefixed with the path of the working directory fixed at the time the JVM is started.

Under Windows ^TM , 'jdbc:hsqldb:file:c:\databases\test' connects to a database located on drive 'C:' in the directory 'databases', composed of some subset of the files:

 C:\
 +--databases\
 +--test.properties
 +--test.script
 +--test.log
 +--test.data
 +--test.backup
 +--test.lck
 

Under most variations of UNIX, 'jdbc:hsqldb:file:/databases/test' connects to a database located in the directory 'databases' directly under root, once again composed of some subset of the files:

 /
 +--databases/
 +--test.properties
 +--test.script
 +--test.log
 +--test.data
 +--test.backup
 +--test.lck
 

Some Guidelines:

1. Both relative and absolute database file paths are supported.

2. Relative database file paths can be specified in a platform independent manner as: '[dir1/dir2/.../dirn/]<file-name-prefix>'.

3. Specification of absolute file paths is operating-system specific.
   Please read your OS file system documentation.

4. Specification of network mounts may be operating-system specific.
   Please read your OS file system documentation.

5. Special care may be needed w.r.t. file path specifications containing whitespace, mixed-case, special characters and/or reserved file names.
   Please read your OS file system documentation.

Note: Versions of HSQLDB previous to 1.7.0 did not support creating directories along the file path specified in the persistent, in-process mode database connection <url> form, in the case that they did not already exist. Starting with HSQLDB 1.7.0, directories will be created if they do not already exist., but only if HSQLDB is built under a version of the compiler greater than JDK 1.1.x.

res: Connections

The new 'jdbc:hsqldb:res:<path>' database connection <url> has different semantics than the 'jdbc:hsqldb:file:<path>' form. The semantics are similar to those of a 'files_readonly' database, but with some additional points to consider.

Specifically, the '<path>' component of a res: type database connection <url> is used to obtain resource URL objects and thereby read the database files as resources on the class path. Moreover, the URL objects must point only to resources contained in one or more jars on the class path (must be jar protocol).

This restriction is enforced to avoid the unfortunate situation in which, because res: database instances do not create a <path>.lck file (they are strictly files-read-only) and because the <path> components of res: and file: database URIs are not checked for file system equivalence, it is possible for the same database files to be accessed concurrently by both file: and res: database instances. That is, without this restriction, it is possible that <path>.data and <path>.properties file content may be written by a file: database instance without the knowlege or cooperation of a res: database instance open on the same files, potentially resulting in unexpected database errors, inconsistent operation and/or data corruption.

In short, a res: type database connection <url> is designed specifically to connect to a 'files_in_jar' mode database instance, which in turn is designed specifically to operate under Java WebStart^TM and Java Applet^TMconfigurations, where co-locating the database files in the jars that make up the WebStart application or Applet avoids the need for special security configuration or code signing.

Note: Since it is difficult and often nearly impossible to determine or control at runtime from where all classes are being loaded or which class loader is doing the loading under 'files_in_jar' semantics, the <path> component of the res: database connection <url> is always taken to be relative to the default package. That is, if the <path> component does not start with '/', then '/' is prepended when obtaining the resource URLs used to read the database files.

---

For more information about HSQLDB file structure, various database modes and other attributes such as those controlled through the HSQLDB properties files, please read the general documentation, especially the Advanced Users Guide.

---

JRE 1.1.x Notes:

In general, JDBC 2 support requires Java 1.2 and above, and JDBC3 requires Java 1.4 and above. In HSQLDB, support for methods introduced in different versions of JDBC depends on the JDK version used for compiling and building HSQLDB.

Since 1.7.0, it is possible to build the product so that all JDBC 2 methods can be called while executing under the version 1.1.x Java Runtime Environment^TM. However, in addition to this technique requiring explicit casts to the org.hsqldb.jdbcXXX classes, some of the method calls also require int values that are defined only in the JDBC 2 or greater version of ResultSet interface. For this reason, when the product is compiled under JDK 1.1.x, these values are defined in org.hsqldb.jdbc.jdbcResultSet jdbcResultSet .

In a JRE 1.1.x environment, calling JDBC 2 methods that take or return the JDBC2-only ResultSet values can be achieved by referring to them in parameter specifications and return value comparisons, respectively, as follows:

 jdbcResultSet.FETCH_FORWARD
 jdbcResultSet.TYPE_FORWARD_ONLY
 jdbcResultSet.TYPE_SCROLL_INSENSITIVE
 jdbcResultSet.CONCUR_READ_ONLY
 // etc.
 

However, please note that code written to use HSQLDB JDBC 2 features under JDK 1.1.x will not be compatible for use with other JDBC 2 drivers. Please also note that this feature is offered solely as a convenience to developers who must work under JDK 1.1.x due to operating constraints, yet wish to use some of the more advanced features available under the JDBC 2 specification.

---

(fredt@users)
(boucherb@users)

HSQLDB-Specific Information:

Starting with HSQLDB 1.7.2, this feature is supported.

HSQLDB-Specific Information:

HSQLDB 1.7.2 does not support this feature.

HSQLDB-Specific Information:

Before HSQLDB 1.7.2, SQLWarning was not supported, and calls to this method are simply ignored.

Starting with HSQLDB 1.7.2, the standard behaviour is implemented.

HSQLDB-Specific Information:

In 1.7.2, INTERNAL Connection objects are not closable from JDBC client code.

HSQLDB-Specific Information:

Starting with HSQLDB 1.7.2, savepoints are supported both in SQL and via the JDBC interface.

Using SQL, savepoints may be set, released and used in rollback as follows:

 SAVEPOINT <savepoint-name>
 RELEASE SAVEPOINT <savepoint-name>
 ROLLBACK TO SAVEPOINT <savepoint-name>
 

HSQLDB-Specific Information:

Starting with HSQLDB 1.7.2, support for precompilation at the engine level has been implemented, so it is now much more efficient and performant to use a PreparedStatement object if the same SQL statement is executed many times.

Up to 1.6.1, HSQLDB supported TYPE_FORWARD_ONLY - CONCUR_READ_ONLY results only, so ResultSet objects created using the returned Statement object would always be type TYPE_FORWARD_ONLY with CONCUR_READ_ONLY concurrency.

Starting with 1.7.0, HSQLDB also supports TYPE_SCROLL_INSENSITIVE results.

Notes:

Up to 1.6.1, calling this method returned null if the connection was already closed. This was possibly counter-intuitive to the expectation that an exception would be thrown for closed connections. Starting with 1.7.0. the behaviour is to throw a SQLException if the connection is closed.

HSQLDB-Specific Information:

Up to HSQLDB 1.6.1, support was provided only for type TYPE_FORWARD_ONLY and concurrency CONCUR_READ_ONLY.

Starting with HSQLDB 1.7.0, support is now provided for types TYPE_FORWARD_ONLY, and TYPE_SCROLL_INSENSITIVE, with concurrency CONCUR_READ_ONLY. Starting with HSQLDB 1.7.2, the behaviour regarding the type and concurrency values has changed to more closely conform to the specification. That is, if an unsupported combination is requested, a SQLWarning is issued on this Connection and the closest supported combination is used instead.

Notes:

Up to 1.6.1, calling this method returned null if the connection was already closed and a supported combination of type and concurrency was specified. This was possibly counter-intuitive to the expectation that an exception would be thrown for closed connections. Starting with 1.7.0. the behaviour is to throw a SQLException if the connection is closed.

HSQLDB-Specific Information:

Starting with HSQLDB 1.7.2, this feature is supported.

Starting with HSQLDB 1.7.2, the behaviour regarding the type, concurrency and holdability values has changed to more closely conform to the specification. That is, if an unsupported combination is requested, a SQLWarning is issued on this Connection and the closest supported combination is used instead.

HSQLDB-Specific Information:

HSQLDB does not yet support catalogs and always returns null.

HSQLDB-Specific Information:

Starting with HSQLDB 1.7.2, this feature is supported.

Calling this method always returns HOLD_CURSORS_OVER_COMMIT.

HSQLDB-Specific Information:

JDBC DatabaseMetaData methods returning ResultSet were not implemented fully before 1.7.2. Some of these methods always returned empty result sets. Other methods did not accurately reflect all of the MetaData for the category. Also, some method ignored the filters provided as parameters, returning an unfiltered result each time.

Also, the majority of methods returning ResultSet threw an SQLException when accessed by a non-admin user.

---

Starting with HSQLDB 1.7.2, essentially full database metadata is supported.

For discussion in greater detail, please follow the link to the overview for jdbcDatabaseMetaData, below.

HSQLDB-Specific Information:

HSQLDB always returns Connection.TRANSACTION_READ_UNCOMMITED.

HSQLDB-Specific Information:

HSQLDB 1.7.2 does not support this feature. Calling this method always throws a SQLException, stating that the function is not supported.

HSQLDB-Specific Information:

Starting with 1.7.2, HSQLDB produces warnings whenever a createStatement(), prepareStatement() or prepareCall() invocation requests an unsupported but defined combination of result set type, concurrency and holdability, such that another set is substituted.

HSQLDB-Specific Information:

Up to and including 1.7.2, HSQLDB converts the JDBC SQL grammar into the system's native SQL grammar prior to sending it, if escape processing is set true; this method returns the native form of the statement that the driver would send in place of client-specified JDBC SQL grammar.

Before 1.7.2, escape processing was incomplete and also broken in terms of support for nested escapes.

Starting with 1.7.2, escape processing is complete and handles nesting to arbitrary depth, but enforces a very strict interpretation of the syntax and does not detect or process SQL comments.

In essence, the HSQLDB engine directly handles the prescribed syntax and date / time formats specified internal to the JDBC escapes. It also directly offers the XOpen / ODBC extended scalar functions specified available internal to the {fn ...} JDBC escape. As such, the driver simply removes the curly braces and JDBC escape codes in the simplest and fastest fashion possible, by replacing them with whitespace. But to avoid a great deal of complexity, certain forms of input whitespace are currently not recognised. For instance, the driver handles "{?= call ...}" but not "{ ?= call ...} or "{? = call ...}"

Also, comments embedded in SQL are currently not detected or processed and thus may have unexpected effects on the output of this method, for instance causing otherwise valid SQL to become invalid. It is especially important to be aware of this because escape processing is set true by default for Statement objects and is always set true when producing a PreparedStatement from prepareStatement() or CallableStatement from prepareCall(). Currently, it is simply recommended to avoid submitting SQL having comments containing JDBC escape sequence patterns and/or single or double quotation marks, as this will avoid any potential problems. It is intended to implement a less strict handling of whitespace and proper processing of SQL comments at some point in the near future, perhaps before the final 1.7.2 release. In any event, 1.7.2 now correctly processes the following JDBC escape forms to arbitrary nesting depth, but only if the exact whitespace layout described below is used:

1. {call ...}
2. {?= call ...}
3. {fn ...}
4. {oj ...}
5. {d ...}
6. {t ...}
7. {ts ...}

HSQLDB-Specific Information:

Starting with 1.7.2, the support for and behaviour of CallableStatement has changed. Please read the introductory section of the documentation for org.hsqldb.jdbc.jdbcCallableStatement.

HSQLDB-Specific Information:

Starting with HSQLDB 1.7.2, the behaviour regarding the type, concurrency and holdability values has changed to more closely conform to the specification. That is, if an unsupported combination is requrested, a SQLWarning is issued on this Connection and the closest supported combination is used instead.

Also starting with 1.7.2, the support for and behaviour of CallableStatement has changed. Please read the introdutory section of the documentation for org.hsqldb.jdbc.jdbcCallableStatement.

HSQLDB-Specific Information:

Starting with HSQLDB 1.7.2, this feature is supported.

Starting with HSQLDB 1.7.2, the behaviour regarding the type, concurrency and holdability values has changed to more closely conform to the specification. That is, if an unsupported combination is requrested, a SQLWarning is issued on this Connection and the closest supported combination is used instead.

Also starting with 1.7.2, the support for and behaviour of CallableStatment has changed. Please read the introdutory section of the documentation for org.hsqldb.jdbc.jdbcCallableStatement.

HSQLDB-Specific Information:

Starting with HSQLDB 1.7.2, support for precompilation at the engine level has been implemented, so it is now much more efficient and performant to use a PreparedStatement object if the same SQL statement is executed many times.

Starting with 1.7.2, the support for and behaviour of PreparedStatment has changed. Please read the introductory section of the documentation for org.hsqldb.jdbc.jdbcPreparedStatement.

HSQLDB-Specific Information:

Starting with HSQLDB 1.7.2, the behaviour regarding the type and concurrency values has changed to more closely conform to the specification. That is, if an unsupported combination is requested, a SQLWarning is issued on this Connection and the closest supported combination is used instead.

Also starting with 1.7.2, the support for and behaviour of PreparedStatment has changed. Please read the introductory section of the documentation for org.hsqldb.jdbc.jdbcPreparedStatement.

HSQLDB-Specific Information:

Starting with HSQLDB 1.7.2, this feature is supported.

Starting with HSQLDB 1.7.2, the behaviour regarding the type, concurrency and holdability values has changed to more closely conform to the specification. That is, if an unsupported combination is requested, a SQLWarning is issued on this Connection and the closest supported combination is used instead.

Also starting with 1.7.2, the support for and behaviour of PreparedStatment has changed. Please read the introductory section of the documentation for org.hsqldb.jdbc.jdbcPreparedStatement.

HSQLDB-Specific Information:

HSQLDB 1.7.2 does not support this feature.

Calling this method always throws a SQLException, stating that the function is not supported.

HSQLDB-Specific Information:

HSQLDB 1.7.2 does not support this feature.

Calling this method always throws a SQLException, stating that the function is not supported.

HSQLDB-Specific Information:

HSQLDB 1.7.2 does not support this feature.

Calling this method always throws a SQLException, stating that the function is not supported.

HSQLDB-Specific Information:

Starting with HSQLDB 1.7.2, savepoints are fully supported both in SQL and via the JDBC interface.

Using SQL, savepoints may be set, released and used in rollback as follows:

 SAVEPOINT <savepoint-name>
 RELEASE SAVEPOINT <savepoint-name>
 ROLLBACK TO SAVEPOINT <savepoint-name>
 

HSQLDB-Specific Information:

Up to and including HSQLDB 1.7.2,

1. All rows of a result set are retrieved internally before the first row can actually be fetched.
   Therefore, a statement can be considered complete as soon as any XXXStatement.executeXXX method returns.
2. Multiple result sets and output parameters are not yet supported.

(boucherb@users)

HSQLDB-Specific Information:

HSQLDB does not yet support catalogs and simply ignores this request.

HSQLDB-Specific Information:

Starting with HSQLDB 1.7.2, this feature is supported.

As of 1.7.2, only HOLD_CURSORS_OVER_COMMIT is supported; supplying any other value will throw an exception.

HSQLDB-Specific Information:

Up to and including 1.7.2, HSQLDB will commit the current transaction automatically when this method is called.

Additionally, HSQLDB provides a way to put a whole database in read-only mode. This is done by manually adding the line 'readonly=true' to the database's .properties file while the database is offline. Upon restart, all connections will be readonly, since the entire database will be readonly. To take a database out of readonly mode, simply take the database offline and remove the line 'readonly=true' from the database's .properties file. Upon restart, the database will be in regular (read-write) mode.

When a database is put in readonly mode, its files are opened in readonly mode, making it possible to create CD-based readonly databases. To create a CD-based readonly database that has CACHED tables and whose .data file is suspected of being highly fragmented, it is recommended that the database first be SHUTDOWN COMPACTed before copying the database files to CD. This will reduce the space required and may improve access times against the .data file which holds the CACHED table data.

Starting with 1.7.2, an alternate approach to opimizing the .data file before creating a CD-based readonly database is to issue the CHECKPOINT DEFRAG command followed by SHUTDOWN to take the database offline in preparation to burn the database files to CD.

HSQLDB-Specific Information:

HSQLDB 1.7.2 does not support this feature.

Calling this method always throws a SQLException, stating that the function is not supported.

Use setSavepoint(String name) instead

HSQLDB-Specific Information:

HSQLDB 1.7.2 does not support this feature. Calling this method always throws a SQLException, stating that the function is not supported.