JDBCConnection (HSQLDB 2.2.9 API)
Date: 2012-08-06

Overview | Package | Class | Use | Tree | Deprecated | Index | Help
PREV CLASS NEXT CLASS | FRAMES NO FRAMES
SUMMARY: NESTED | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD

## org.hsqldb.jdbc
Class JDBCConnection

    java.lang.Object
      org.hsqldb.jdbc.JDBCConnection

All Implemented Interfaces:
  Connection, Wrapper

    public class JDBCConnection

extends Object
implements Connection

A connection (session) with a specific database. SQL statements are executed and results are returned within the context of a connection.

A `Connection` object's database is able to provide information describing its tables, its supported SQL grammar, its stored procedures, the capabilities of this connection, and so on. This information is obtained with the `getMetaData` method.

(JDBC4 clarification:)

Note: When configuring a `Connection`, JDBC applications should use the appropritate `Connection` method such as `setAutoCommit` or `setTransactionIsolation`. Applications should not invoke SQL commands directly to change the connection's configuration when there is a JDBC method available. By default a `Connection` object is in auto-commit mode, which means that it automatically commits changes after executing each statement. If auto-commit mode has been disabled, the method `commit` must be called explicitly in order to commit changes; otherwise, database changes will not be saved.

A new `Connection` object created using the JDBC 2.1 core API has an initially empty type map associated with it. A user may enter a custom mapping for a UDT in this type map. When a UDT is retrieved from a data source with the method `ResultSet.getObject`, the `getObject` method will check the connection's type map to see if there is an entry for that UDT. If so, the `getObject` method will map the UDT to the class indicated. If there is no entry, the UDT will be mapped using the standard mapping.

A user may create a new type map, which is a `java.util.Map` object, make an entry in it, and pass it to the `java.sql` methods that can perform custom mapping. In this case, the method will use the given type map instead of the one associated with the connection.

For example, the following code fragment specifies that the SQL type `ATHLETES` will be mapped to the class `Athletes` in the Java programming language. The code fragment retrieves the type map for the `Connection` object `con`, inserts the entry into it, and then sets the type map with the new entry as the connection's type map.

          java.util.Map map = con.getTypeMap();
          map.put("mySchemaName.ATHLETES", Class.forName("Athletes"));
          con.setTypeMap(map);

### 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 `Server` database connection <url> takes one of the two following forms:

1. 'jdbc:hsqldb:hsql://host[:port][/<alias>][<key-value-pairs>]'
2. 'jdbc:hsqldb:hsqls://host[:port][/<alias>][<key-value-pairs>]' (with TLS).

The `WebServer` database connection <url> takes one of two following forms:

1. 'jdbc:hsqldb:http://host[:port][/<alias>][<key-value-pairs>]'
2. 'jdbc:hsqldb:https://host[:port][/<alias>][<key-value-pairs>]' (with TLS).

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, if such an instance is available.

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

Transient, In-Process Database Connections:

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

1. 'jdbc:hsqldb:.[<key-value-pairs>]' (the legacy form, extended)
2. 'jdbc:hsqldb:mem:<alias>[<key-value-pairs>]' (the new form)

The driver converts the supplied <alias> component to Local.ENGLISH lower case and uses the resulting character sequence as the key used to look up a mem: protocol 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.

The rationale for converting the supplied <alias> component to lower case is to provide consistency with the behavior of res: protocol database connection <url>s, explained further on in this overview.

Persistent, In-Process Database Connections:

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

1. 'jdbc:hsqldb:<path>[<key-value-pairs>]' (the legacy form, extended)
2. 'jdbc:hsqldb:file:<path>[<key-value-pairs>]' (same semantics as the legacy form)
3. 'jdbc:hsqldb:res:<path>[<key-value-pairs>]' (new form with 'files_in_jar' semantics)

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.

From 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 is:

- <path>.properties
- <path>.script
- <path>.log
- <path>.data
- <path>.backup
- <path>.lck

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 canonical path of the JVM's effective working directory at the time the designated database is first opened in-process.

Be careful to note that this canonical expansion of <path> is cached by the driver until JVM exit. So, although legacy JVMs tend to fix the reported effective working directory at the one noted upon JVM startup, there is no guarantee that modern JVMs will continue to uphold this behaviour. What this means is there is effectively no guarantee into the future that a relative file: protocol database connection <url> will connect to the same database instance for the life of the JVM. To avoid any future ambigutity issues, it is probably a best practice for clients to attempt to pre-canonicalize the <path> component of file: protocol database connection* <url>s.

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: protocol Connections:

The '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: protocol database connection <url> is first converted to lower case with `Locale.ENGLISH` and only then used to obtain resource URL objects, which in turn are used to read the database files as resources on the class path.

Due to lower case conversion by the driver, res: '<path>' components never find jar resources stored with `Locale.ENGLISH` mixed case paths. The rationale for converting to lower case is that not all pkzip implementations guarantee path case is preserved when archiving resources, and conversion to lower case seems to be the most common occurrence (although there is also no actual guarantee that the conversion is `Locale.ENGLISH`).

More importantly, res: '<path>' components must point only to resources contained in one or more jars on the class path. That is, only resources having the jar sub-protocol are considered valid.

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 `URI`s 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 WebStartTM and Java AppletTMconfigurations, 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 (and hence how relative path specifications are resolved) under 'files_in_jar' semantics, the <path> component of the res: database connection <url> is always taken to be relative to the default package and resource URL resolution is always performed using the ClassLoader that loads the org.hsqldb.persist.Logger class. That is, if the <path> component does not start with '/', then'/' is prepended when obtaining the resource URLs used to read the database files, and only the effective class path of org.hsqldb.persist.Logger's ClassLoader is searched.

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 EnvironmentTM. However, in addition to this technique requiring explicit casts to the org.hsqldb.jdbc.* classes, some of the method calls also require `int` values that are defined only in the JDBC 2 or greater version of the `ResultSet` interface. For this reason, when the product is compiled under JDK 1.1.x, these values are defined in `JDBCResultSet`.

In a JRE 1.1.x environment, calling JDBC 2 methods that take or return the JDBC 2+ `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.

JDBC 4.0 Notes:

Starting with JDBC 4.0 (JDK 1.6), the `DriverManager` methods `getConnection` and `getDrivers` have been enhanced to support the Java Standard Edition Service Provider mechanism. When built under a Java runtime that supports JDBC 4.0, HSQLDB distribution jars containing the Driver implementation also include the file `META-INF/services/java.sql.Driver`. This file contains the fully qualified class name ('org.hsqldb.jdbc.JDBCDriver') of the HSQLDB implementation of `java.sql.Driver`.

Hence, under JDBC 4.0 or greater, applications no longer need to explictly load the HSQLDB JDBC driver using `Class.forName()`. Of course, existing programs which do load JDBC drivers using `Class.forName()` will continue to work without modification.

(fredt@users)
(boucherb@users)

Author:
  Campbell Boucher-Burnet (boucherb@users dot sourceforge.net), Fred Toussi (fredt@users dot sourceforge.net)
See Also:
  `JDBCDriver`, `JDBCStatement`, `JDBCParameterMetaData`, `JDBCCallableStatement`, `JDBCResultSet`, `JDBCDatabaseMetaData`, `DriverManager.getConnection(java.lang.String, java.util.Properties)`, `Statement`, `ResultSet`, `DatabaseMetaData`

Field Summary

Fields inherited from interface java.sql.Connection
`TRANSACTION_NONE, TRANSACTION_READ_COMMITTED, TRANSACTION_READ_UNCOMMITTED, TRANSACTION_REPEATABLE_READ, TRANSACTION_SERIALIZABLE`

Constructor Summary
`JDBCConnection(org.hsqldb.persist.HsqlProperties props)` Constructs a new external `Connection` to an HSQLDB `Database`.
`JDBCConnection(JDBCConnection c, JDBCConnectionEventListener eventListener)` Constructor for use with connection pooling and XA.
`JDBCConnection(org.hsqldb.SessionInterface c)` Constructs an `INTERNAL` `Connection`, using the specified `SessionInterface`.

Method Summary
`void` | `abort(Executor executor)` Terminates an open connection.
`void` | `clearWarnings()` Clears all warnings reported for this `Connection` object.
`void` | `close()` Releases this `Connection` object's database and JDBC resources immediately instead of waiting for them to be automatically released.
`void` | `closeFully()` Completely closes a pooled connection
`void` | `commit()` Makes all changes made since the previous commit/rollback permanent and releases any database locks currently held by this `Connection` object.
`Array` | `createArrayOf(String typeName, Object[] elements)` Factory method for creating Array objects.
`Blob` | `createBlob()` Constructs an object that implements the `Blob` interface.
`Clob` | `createClob()` Constructs an object that implements the `Clob` interface.
`NClob` | `createNClob()` Constructs an object that implements the `NClob` interface.
`SQLXML` | `createSQLXML()` Constructs an object that implements the `SQLXML` interface.
`Statement` | `createStatement()` Creates a `Statement` object for sending SQL statements to the database.
`Statement` | `createStatement(int resultSetType, int resultSetConcurrency)` Creates a `Statement` object that will generate `ResultSet` objects with the given type and concurrency.
`Statement` | `createStatement(int resultSetType, int resultSetConcurrency, int resultSetHoldability)` Creates a `Statement` object that will generate `ResultSet` objects with the given type, concurrency, and holdability.
`Struct` | `createStruct(String typeName, Object[] attributes)` Factory method for creating Struct objects.
`boolean` | `getAutoCommit()` Retrieves the current auto-commit mode for this `Connection` object.
`String` | `getCatalog()` Retrieves this `Connection` object's current catalog name.
`Properties` | `getClientInfo()` Returns a list containing the name and current value of each client info property supported by the driver.
`String` | `getClientInfo(String name)` Returns the value of the client info property specified by name.
`int` | `getHoldability()` Retrieves the current holdability of `ResultSet` objects created using this `Connection` object.
`DatabaseMetaData` | `getMetaData()` Retrieves a `DatabaseMetaData` object that contains metadata about the database to which this `Connection` object represents a connection.
`int` | `getNetworkTimeout()` Retrieves the number of milliseconds the driver will wait for a database request to complete.
`String` | `getSchema()` Retrieves this `Connection` object's current schema name.
`org.hsqldb.SessionInterface` | `getSession()` provides cross-package access to the proprietary (i.e.
`int` | `getTransactionIsolation()` Retrieves this `Connection` object's current transaction isolation level.
`Map<String,Class<?>>` | `getTypeMap()` Retrieves the `Map` object associated with this `Connection` object.
`SQLWarning` | `getWarnings()` Retrieves the first warning reported by calls on this `Connection` object.
`boolean` | `isClosed()` Retrieves whether this `Connection` object has been closed.
`boolean` | `isReadOnly()` Retrieves whether this `Connection` object is in read-only mode.
`boolean` | `isValid(int timeout)` Returns true if the connection has not been closed and is still valid.
`boolean` | `isWrapperFor(Class<?> iface)` Returns true if this either implements the interface argument or is directly or indirectly a wrapper for an object that does.
`String` | `nativeSQL(String sql)` Converts the given SQL statement into the system's native SQL grammar.
`CallableStatement` | `prepareCall(String sql)` Creates a `CallableStatement` object for calling database stored procedures.
`CallableStatement` | `prepareCall(String sql, int resultSetType, int resultSetConcurrency)` Creates a `CallableStatement` object that will generate `ResultSet` objects with the given type and concurrency.
`CallableStatement` | `prepareCall(String sql, int resultSetType, int resultSetConcurrency, int resultSetHoldability)` Creates a `CallableStatement` object that will generate `ResultSet` objects with the given type and concurrency.
`PreparedStatement` | `prepareStatement(String sql)` Creates a `PreparedStatement` object for sending parameterized SQL statements to the database.
`PreparedStatement` | `prepareStatement(String sql, int autoGeneratedKeys)` Creates a default `PreparedStatement` object that has the capability to retrieve auto-generated keys.
`PreparedStatement` | `prepareStatement(String sql, int[] columnIndexes)` Creates a default `PreparedStatement` object capable of returning the auto-generated keys designated by the given array.
`PreparedStatement` | `prepareStatement(String sql, int resultSetType, int resultSetConcurrency)` Creates a `PreparedStatement` object that will generate `ResultSet` objects with the given type and concurrency.
`PreparedStatement` | `prepareStatement(String sql, int resultSetType, int resultSetConcurrency, int resultSetHoldability)` Creates a `PreparedStatement` object that will generate `ResultSet` objects with the given type, concurrency, and holdability.
`PreparedStatement` | `prepareStatement(String sql, String[] columnNames)` Creates a default `PreparedStatement` object capable of returning the auto-generated keys designated by the given array.
`void` | `releaseSavepoint(Savepoint savepoint)` Removes the specified `Savepoint` (JDBC4 Clarification:) and subsequent `Savepoint` objects from the current transaction.
`void` | `reset()` Resets this connection so it can be used again.
`void` | `rollback()` Undoes all changes made in the current transaction and releases any database locks currently held by this `Connection` object.
`void` | `rollback(Savepoint savepoint)` Undoes all changes made after the given `Savepoint` object was set.
`void` | `setAutoCommit(boolean autoCommit)` Sets this connection's auto-commit mode to the given state.
`void` | `setCatalog(String catalog)` Sets the given catalog name in order to select a subspace of this `Connection` object's database in which to work.
`void` | `setClientInfo(Properties properties)` Sets the value of the connection's client info properties.
`void` | `setClientInfo(String name, String value)` Sets the value of the client info property specified by name to the value specified by value.
`void` | `setHoldability(int holdability)` (JDBC4 Clarification:) Changes the default holdability of `ResultSet` objects created using this `Connection` object to the given holdability.
`void` | `setNetworkTimeout(Executor executor, int milliseconds)` Sets the maximum period a `Connection` or objects created from the `Connection` will wait for the database to reply to any one request.
`void` | `setReadOnly(boolean readOnly)` Puts this connection in read-only mode as a hint to the driver to enable database optimizations.
`Savepoint` | `setSavepoint()` Creates an unnamed savepoint in the current transaction and returns the new `Savepoint` object that represents it.
`Savepoint` | `setSavepoint(String name)` Creates a savepoint with the given name in the current transaction and returns the new `Savepoint` object that represents it.
`void` | `setSchema(String schema)` Sets the given schema name to access.
`void` | `setTransactionIsolation(int level)` Attempts to change the transaction isolation level for this `Connection` object to the one given.
`void` | `setTypeMap(Map<String,Class<?>> map)` Installs the given `TypeMap` object as the type map for this `Connection` object.
`
`<T> T`
` | `unwrap(Class<T> iface)` Returns an object that implements the given interface to allow access to non-standard methods, or standard methods not exposed by the proxy.

Methods inherited from class java.lang.Object
`equals, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait`

Constructor Detail

### JDBCConnection

    public JDBCConnection(org.hsqldb.persist.HsqlProperties props)
                   throws SQLException

  Constructs a new external `Connection` to an HSQLDB `Database`.

  This constructor is called on behalf of the `java.sql.DriverManager` when getting a `Connection` for use in normal (external) client code.

  Internal client code, that being code located in HSQLDB SQL functions and stored procedures, receives an INTERNAL connection constructed by the `JDBCConnection(SessionInterface)` constructor.

  Parameters:
    `props` - A `Properties` object containing the connection properties
  Throws:
    `SQLException` - when the user/password combination is invalid, the connection url is invalid, or the `Database` is unavailable.

    The `Database` may be unavailable for a number of reasons, including network problems or the fact that it may already be in use by another process.

### JDBCConnection

    public JDBCConnection(org.hsqldb.SessionInterface c)

  Constructs an `INTERNAL` `Connection`, using the specified `SessionInterface`.

  This constructor is called only on behalf of an existing `Session` (the internal parallel of a `Connection`), to be used as a parameter to a SQL function or stored procedure that needs to execute in the context of that `Session`.

  When a Java SQL function or stored procedure is called and its first parameter is of type `Connection`, HSQLDB automatically notices this and constructs an `INTERNAL` `Connection` using the current `Session`. HSQLDB then passes this `Connection` in the first parameter position, moving any other parameter values specified in the SQL statement to the right by one position.

  To read more about this, see `Routine`.

  Notes:

  Starting with HSQLDB 1.7.2, `INTERNAL` connections are not closed by a call to close() or by a SQL DISCONNECT. For HSQLDB developers not involved with writing database internals, this change only applies to connections obtained automatically from the database as the first parameter to Java stored procedures and functions. This is mainly an issue to developers writing custom SQL function and stored procedure libraries for HSQLDB. Presently, it is recommended that SQL function and stored procedure code avoid depending on closing or issuing a DISCONNECT on a connection obtained in this manner.

  Parameters:
    `c` - the Session requesting the construction of this Connection
  Throws:
    `org.hsqldb.HsqlException` - never (reserved for future use);
  See Also:
    `Routine`

### JDBCConnection

    public JDBCConnection(JDBCConnection c,
                          JDBCConnectionEventListener eventListener)

  Constructor for use with connection pooling and XA.

Method Detail

### createStatement

    public Statement createStatement()
                              throws SQLException

  Creates a `Statement` object for sending SQL statements to the database. SQL statements without parameters are normally executed using `Statement` objects. If the same SQL statement is executed many times, it may be more efficient to use a `PreparedStatement` object.

  Result sets created using the returned `Statement` object will by default be type `TYPE_FORWARD_ONLY` and have a concurrency level of `CONCUR_READ_ONLY`. The holdability of the created result sets can be determined by calling `getHoldability()`.

  ### 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 short-running SQL statement is to be executed many times.

  HSQLDB supports `TYPE_FORWARD_ONLY`, `TYPE_SCROLL_INSENSITIVE` and `CONCUR_READ_ONLY` results.

  Specified by:
    `createStatement` in interface `Connection`
  Returns:
    a new default `Statement` object
  Throws:
    `SQLException` - if a database access error occurs (JDBC4 clarification:) or this method is called on a closed connection
  See Also:
    `createStatement(int,int)`, `createStatement(int,int,int)`

### prepareStatement

    public PreparedStatement prepareStatement(String sql)
                                       throws SQLException

  Creates a `PreparedStatement` object for sending parameterized SQL statements to the database.

  A SQL statement with or without IN parameters can be pre-compiled and stored in a `PreparedStatement` object. This object can then be used to efficiently execute this statement multiple times.

  Note: This method is optimized for handling parametric SQL statements that benefit from precompilation. If the driver supports precompilation, the method `prepareStatement` will send the statement to the database for precompilation. Some drivers may not support precompilation. In this case, the statement may not be sent to the database until the `PreparedStatement` object is executed. This has no direct effect on users; however, it does affect which methods throw certain `SQLException` objects.

  Result sets created using the returned `PreparedStatement` object will by default be type `TYPE_FORWARD_ONLY` and have a concurrency level of `CONCUR_READ_ONLY`. The holdability of the created result sets can be determined by calling `getHoldability()`.

  ### 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 short-running SQL statement is to be executed many times.

  The support for and behaviour of PreparedStatment complies with SQL and JDBC standards. Please read the introductory section of the documentation for ${link JDBCParameterMetaData}.

  Specified by:
    `prepareStatement` in interface `Connection`
  Parameters:
    `sql` - an SQL statement that may contain one or more '?' IN parameter placeholders
  Returns:
    a new default `PreparedStatement` object containing the pre-compiled SQL statement
  Throws:
    `SQLException` - if a database access error occurs (JDBC4 clarification:) or this method is called on a closed connection
  See Also:
    `prepareStatement(String,int,int)`

### prepareCall

    public CallableStatement prepareCall(String sql)
                                  throws SQLException

  Creates a `CallableStatement` object for calling database stored procedures. The `CallableStatement` object provides methods for setting up its IN and OUT parameters, and methods for executing the call to a stored procedure.

  Note: This method is optimized for handling stored procedure call statements. Some drivers may send the call statement to the database when the method `prepareCall` is done; others may wait until the `CallableStatement` object is executed. This has no direct effect on users; however, it does affect which method throws certain SQLExceptions.

  Result sets created using the returned `CallableStatement` object will by default be type `TYPE_FORWARD_ONLY` and have a concurrency level of `CONCUR_READ_ONLY`. The holdability of the created result sets can be determined by calling `getHoldability()`.

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

  Specified by:
    `prepareCall` in interface `Connection`
  Parameters:
    `sql` - an SQL statement that may contain one or more '?' parameter placeholders. (JDBC4 clarification:) Typically this statement is specified using JDBC call escape syntax.
  Returns:
    a new default `CallableStatement` object containing the pre-compiled SQL statement
  Throws:
    `SQLException` - if a database access error occurs (JDBC4 clarification:) or this method is called on a closed connection
  See Also:
    `prepareCall(String,int,int)`

### nativeSQL

    public String nativeSQL(String sql)
                     throws SQLException

  Converts the given SQL statement into the system's native SQL grammar. A driver may convert the JDBC SQL grammar into its system's native SQL grammar prior to sending it. This method returns the native form of the statement that the driver would have sent.

  ### HSQLDB-Specific Information:

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

  Specified by:
    `nativeSQL` in interface `Connection`
  Parameters:
    `sql` - an SQL statement that may contain one or more '?' parameter placeholders
  Returns:
    the native form of this statement
  Throws:
    `SQLException` - if a database access error occurs (JDBC4 clarification:) or this method is called on a closed connection

### setAutoCommit

    public void setAutoCommit(boolean autoCommit)
                       throws SQLException

  Sets this connection's auto-commit mode to the given state. If a connection is in auto-commit mode, then all its SQL statements will be executed and committed as individual transactions. Otherwise, its SQL statements are grouped into transactions that are terminated by a call to either the method `commit` or the method `rollback`. By default, new connections are in auto-commit mode.

  The commit occurs when the statement completes. The time when the statement completes depends on the type of SQL Statement:

  - For DML statements, such as Insert, Update or Delete, and DDL statements, the statement is complete as soon as it has finished executing.
  - For Select statements, the statement is complete when the associated result set is closed.
  - For `CallableStatement` objects or for statements that return multiple results, the statement is complete when all of the associated result sets have been closed, and all update counts and output parameters have been retrieved.

  NOTE: If this method is called during a transaction and the auto-commit mode is changed, the transaction is committed. If `setAutoCommit` is called and the auto-commit mode is not changed, the call is a no-op.

  ### HSQLDB-Specific Information:

  Up to and including HSQLDB 2.0,

  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.

  Starting with 2.0, HSQLDB may not return a result set to the network client as a whole; the generic documentation will apply. The fetch size is taken into account (boucherb@users)

  Specified by:
    `setAutoCommit` in interface `Connection`
  Parameters:
    `autoCommit` - `true` to enable auto-commit mode; `false` to disable it
  Throws:
    `SQLException` - if a database access error occurs, (JDBC4 Clarification:) setAutoCommit(true) is called while participating in a distributed transaction, or this method is called on a closed connection
  See Also:
    `getAutoCommit()`

### getAutoCommit

    public boolean getAutoCommit()
                          throws SQLException

  Retrieves the current auto-commit mode for this `Connection` object.

  Specified by:
    `getAutoCommit` in interface `Connection`
  Returns:
    the current state of this `Connection` object's auto-commit mode
  Throws:
    `SQLException` - if a database access error occurs (JDBC4 Clarification:) or this method is called on a closed connection
  See Also:
    `setAutoCommit(boolean)`

### commit

    public void commit()
                throws SQLException

  Makes all changes made since the previous commit/rollback permanent and releases any database locks currently held by this `Connection` object. This method should be used only when auto-commit mode has been disabled.

  ### HSQLDB-Specific Information:

  Specified by:
    `commit` in interface `Connection`
  Throws:
    `SQLException` - if a database access error occurs, (JDBC4 Clarification:) this method is called while participating in a distributed transaction, if this method is called on a closed connection or this `Connection` object is in auto-commit mode
  See Also:
    `setAutoCommit(boolean)`

### rollback

    public void rollback()
                  throws SQLException

  Undoes all changes made in the current transaction and releases any database locks currently held by this `Connection` object. This method should be used only when auto-commit mode has been disabled.

  ### 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>

  Specified by:
    `rollback` in interface `Connection`
  Throws:
    `SQLException` - if a database access error occurs, (JDBC4 Clarification:) this method is called while participating in a distributed transaction, this method is called on a closed connection or this `Connection` object is in auto-commit mode
  See Also:
    `setAutoCommit(boolean)`

### close

    public void close()
               throws SQLException

  Releases this `Connection` object's database and JDBC resources immediately instead of waiting for them to be automatically released.

  Calling the method `close` on a `Connection` object that is already closed is a no-op.

  It is strongly recommended that an application explicitly commits or rolls back an active transaction prior to calling the `close` method. If the `close` method is called and there is an active transaction, the results are implementation-defined.

  ### HSQLDB-Specific Information:

  From 1.7.2, HSQLDB `INTERNAL` `Connection` objects are not closable from JDBC client code.

  Specified by:
    `close` in interface `Connection`
  Throws:
    `SQLException` - SQLException if a database access error occurs

### isClosed

    public boolean isClosed()
                     throws SQLException

  Retrieves whether this `Connection` object has been closed. A connection is closed if the method `close` has been called on it or if certain fatal errors have occurred. This method is guaranteed to return `true` only when it is called after the method `Connection.close` has been called.

  This method generally cannot be called to determine whether a connection to a database is valid or invalid. A typical client can determine that a connection is invalid by catching any exceptions that might be thrown when an operation is attempted.

  Specified by:
    `isClosed` in interface `Connection`
  Returns:
    `true` if this `Connection` object is closed; `false` if it is still open
  Throws:
    `SQLException` - if a database access error occurs

### getMetaData

    public DatabaseMetaData getMetaData()
                                 throws SQLException

  Retrieves a `DatabaseMetaData` object that contains metadata about the database to which this `Connection` object represents a connection. The metadata includes information about the database's tables, its supported SQL grammar, its stored procedures, the capabilities of this connection, and so on.

  ### HSQLDB-Specific Information:

  HSQLDB 2.0 essentially supports full database metadata.

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

  Specified by:
    `getMetaData` in interface `Connection`
  Returns:
    a `DatabaseMetaData` object for this `Connection` object
  Throws:
    `SQLException` - if a database access error occurs (JDBC4 Clarification) or this method is called on a closed connection
  See Also:
    `JDBCDatabaseMetaData`

### setReadOnly

    public void setReadOnly(boolean readOnly)
                     throws SQLException

  Puts this connection in read-only mode as a hint to the driver to enable database optimizations.

  Note: This method cannot be called during a transaction.

  ### HSQLDB-Specific Information:

  HSQLDB 2.0 supports the SQL standard, which will not allow calls to this method to succeed during a transaction.

  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.

  Specified by:
    `setReadOnly` in interface `Connection`
  Parameters:
    `readOnly` - `true` enables read-only mode; `false` disables it
  Throws:
    `SQLException` - if a database access error occurs, this (JDBC4 Clarification:) method is called on a closed connection or this method is called during a transaction

### isReadOnly

    public boolean isReadOnly()
                       throws SQLException

  Retrieves whether this `Connection` object is in read-only mode.

  Specified by:
    `isReadOnly` in interface `Connection`
  Returns:
    `true` if this `Connection` object is read-only; `false` otherwise
  Throws:
    `SQLException` - SQLException if a database access error occurs (JDBC4 Clarification:) or this method is called on a closed connection

### setCatalog

    public void setCatalog(String catalog)
                    throws SQLException

  Sets the given catalog name in order to select a subspace of this `Connection` object's database in which to work.

  (JDBC4 Clarification:)

  If the driver does not support catalogs, it will silently ignore this request. JDBC 4.1[

  Calling `setCatalog` has no effect on previously created or prepared `Statement` objects. It is implementation defined whether a DBMS prepare operation takes place immediately when the `Connection` method `prepareStatement` or `prepareCall` is invoked. For maximum portability, `setCatalog` should be called before a `Statement` is created or prepared.]

  ### HSQLDB-Specific Information:

  HSQLDB supports a single catalog per database. If the given catalog name is not the same as the database catalog name, this method throws an error.

  Specified by:
    `setCatalog` in interface `Connection`
  Parameters:
    `catalog` - the name of a catalog (subspace in this `Connection` object's database) in which to work
  Throws:
    `SQLException` - if a database access error occurs (JDBC4 Clarification) or this method is called on a closed connection
  See Also:
    `getCatalog()`

### getCatalog

    public String getCatalog()
                      throws SQLException

  Retrieves this `Connection` object's current catalog name.

  ### HSQLDB-Specific Information:

  HSQLDB supports a single catalog per database. This method returns the catalog name for the current database error.

  Specified by:
    `getCatalog` in interface `Connection`
  Returns:
    the current catalog name or `null` if there is none
  Throws:
    `SQLException` - if a database access error occurs (JDBC4 Clarification:) or this method is called on a closed connection
  See Also:
    `setCatalog(java.lang.String)`

### setTransactionIsolation

    public void setTransactionIsolation(int level)
                                 throws SQLException

  Attempts to change the transaction isolation level for this `Connection` object to the one given. The constants defined in the interface `Connection` are the possible transaction isolation levels.

  Note: If this method is called during a transaction, the result is implementation-defined.

  ### HSQLDB-Specific Information:

  HSQLDB 2.0 accepts all isolation levels. `Connection.TRANSACTION_READ_UNCOMMITED` is promoted to `Connection.TRANSACTION_READ_COMMITED, but the transactions become read only`. Calling this method during a transaction always succeeds and the selected isolation level is used from the next transaction.

  Specified by:
    `setTransactionIsolation` in interface `Connection`
  Parameters:
    `level` - one of the following `Connection` constants: `Connection.TRANSACTION_READ_UNCOMMITTED`, `Connection.TRANSACTION_READ_COMMITTED`, `Connection.TRANSACTION_REPEATABLE_READ`, or `Connection.TRANSACTION_SERIALIZABLE`. (Note that `Connection.TRANSACTION_NONE` cannot be used because it specifies that transactions are not supported.)
  Throws:
    `SQLException` - if a database access error occurs, this (JDBC4 Clarification:) method is called on a closed connection (:JDBC4 End Clarification) or the given parameter is not one of the `Connection` constants
  See Also:
    `JDBCDatabaseMetaData.supportsTransactionIsolationLevel(int)`, `getTransactionIsolation()`

### getTransactionIsolation

    public int getTransactionIsolation()
                                throws SQLException

  Retrieves this `Connection` object's current transaction isolation level.

  ### HSQLDB-Specific Information:

  HSQLDB 2.0 supports all isolation levels. `Connection.TRANSACTION_READ_UNCOMMITED` is promoted to `Connection.TRANSACTION_READ_COMMITED`.

  Specified by:
    `getTransactionIsolation` in interface `Connection`
  Returns:
    the current transaction isolation level, which will be one of the following constants: `Connection.TRANSACTION_READ_UNCOMMITTED`, `Connection.TRANSACTION_READ_COMMITTED`, `Connection.TRANSACTION_REPEATABLE_READ`, `Connection.TRANSACTION_SERIALIZABLE`, or `Connection.TRANSACTION_NONE`.
  Throws:
    `SQLException` - if a database access error occurs (JDBC4 Clarification:) or this method is called on a closed connection
  See Also:
    `JDBCDatabaseMetaData.supportsTransactionIsolationLevel(int)`, `setTransactionIsolation(int)`

### getWarnings

    public SQLWarning getWarnings()
                           throws SQLException

  Retrieves the first warning reported by calls on this `Connection` object. If there is more than one warning, subsequent warnings will be chained to the first one and can be retrieved by calling the method `SQLWarning.getNextWarning` on the warning that was retrieved previously.

  This method may not be called on a closed connection; doing so will cause an `SQLException` to be thrown.

  Note: Subsequent warnings will be chained to this SQLWarning.

  ### HSQLDB-Specific Information:

  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.

  Other warnings are typically raised during the execution of data change and query statements.

  Only the warnings caused by the last operation on this connection are returned by this method. A single operation may return up to 10 chained warnings.

  Specified by:
    `getWarnings` in interface `Connection`
  Returns:
    the first `SQLWarning` object or `null` if there are none
  Throws:
    `SQLException` - if a database access error occurs or this method is called on a closed connection
  See Also:
    `SQLWarning`

### clearWarnings

    public void clearWarnings()
                       throws SQLException

  Clears all warnings reported for this `Connection` object. After a call to this method, the method `getWarnings` returns `null` until a new warning is reported for this `Connection` object.

  ### HSQLDB-Specific Information:

  The standard behaviour is implemented.

  Specified by:
    `clearWarnings` in interface `Connection`
  Throws:
    `SQLException` - SQLException if a database access error occurs (JDBC4 Clarification:) or this method is called on a closed connection

### createStatement

    public Statement createStatement(int resultSetType,
                                     int resultSetConcurrency)
                              throws SQLException

  Creates a `Statement` object that will generate `ResultSet` objects with the given type and concurrency. This method is the same as the `createStatement` method above, but it allows the default result set type and concurrency to be overridden. The holdability of the created result sets can be determined by calling `getHoldability()`.

  ### HSQLDB-Specific Information:

  HSQLDB 2.0 adheres closely to SQL and JDBC standards. The interpretation of of resultSetType and resultSetConcurrency has changed in this version.

  HSQLDB supports `TYPE_FORWARD_ONLY`, `TYPE_SCROLL_INSENSITIVE`, `CONCUR_READ_ONLY`, `CONCUR_UPDATABLE` results.

  If an unsupported combination is requested, a SQLWarning is issued on this Connection and the closest supported combination is used instead.

  Specified by:
    `createStatement` in interface `Connection`
  Parameters:
    `resultSetType` - a result set type; one of `ResultSet.TYPE_FORWARD_ONLY`, `ResultSet.TYPE_SCROLL_INSENSITIVE`, or `ResultSet.TYPE_SCROLL_SENSITIVE`
    `resultSetConcurrency` - a concurrency type; one of `ResultSet.CONCUR_READ_ONLY` or `ResultSet.CONCUR_UPDATABLE`
  Returns:
    a new `Statement` object that will generate `ResultSet` objects with the given type and concurrency
  Throws:
    `SQLException` - if a database access error occurs, this (JDBC4 Clarification:) method is called on a closed connection (:JDBC4 Clarification) or the given parameters are not `ResultSet` constants indicating type and concurrency
    `SQLFeatureNotSupportedException` - if the JDBC driver does not support this method or this method is not supported for the specified result set type and result set concurrency.
  Since:
    JDK 1.2 (JDK 1.1.x developers: read the overview for JDBCConnection)

### prepareStatement

    public PreparedStatement prepareStatement(String sql,
                                              int resultSetType,
                                              int resultSetConcurrency)
                                       throws SQLException

  Creates a `PreparedStatement` object that will generate `ResultSet` objects with the given type and concurrency. This method is the same as the `prepareStatement` method above, but it allows the default result set type and concurrency to be overridden. (JDBC4 Clarification:) The holdability of the created result sets can be determined by calling `getHoldability()`.

  ### HSQLDB-Specific Information:

  HSQLDB 2.0 adheres closely to SQL and JDBC standards. The interpretation of of resultSetType and resultSetConcurrency has changed in this version.

  HSQLDB supports `TYPE_FORWARD_ONLY`, `TYPE_SCROLL_INSENSITIVE`, `CONCUR_READ_ONLY`, `CONCUR_UPDATABLE` results.

  If an unsupported combination is requested, a SQLWarning is issued on this Connection and the closest supported combination is used instead.

  Specified by:
    `prepareStatement` in interface `Connection`
  Parameters:
    `sql` - a `String` object that is the SQL statement to be sent to the database; may contain one or more '?' IN parameters
    `resultSetType` - a result set type; one of `ResultSet.TYPE_FORWARD_ONLY`, `ResultSet.TYPE_SCROLL_INSENSITIVE`, or `ResultSet.TYPE_SCROLL_SENSITIVE`
    `resultSetConcurrency` - a concurrency type; one of `ResultSet.CONCUR_READ_ONLY` or `ResultSet.CONCUR_UPDATABLE`
  Returns:
    a new PreparedStatement object containing the pre-compiled SQL statement that will produce `ResultSet` objects with the given type and concurrency
  Throws:
    `SQLException` - if a database access error occurs, this (JDBC4 Clarification:) method is called on a closed connection (:JDBC4 Clarification) or the given parameters are not `ResultSet` constants indicating type and concurrency
    `SQLFeatureNotSupportedException` - if the JDBC driver does not support this method or this method is not supported for the specified result set type and result set concurrency.
  Since:
    JDK 1.2 (JDK 1.1.x developers: read the overview for JDBCConnection)

### prepareCall

    public CallableStatement prepareCall(String sql,
                                         int resultSetType,
                                         int resultSetConcurrency)
                                  throws SQLException

  Creates a `CallableStatement` object that will generate `ResultSet` objects with the given type and concurrency. This method is the same as the `prepareCall` method above, but it allows the default result set type and concurrency to be overridden. (JDBC4 Clarification:) The holdability of the created result sets can be determined by calling `getHoldability()`.

  ### HSQLDB-Specific Information:

  HSQLDB 2.0 adheres closely to SQL and JDBC standards. The interpretation of of resultSetType and resultSetConcurrency has changed in this version.

  HSQLDB supports `TYPE_FORWARD_ONLY`, `TYPE_SCROLL_INSENSITIVE`, `CONCUR_READ_ONLY`, `CONCUR_UPDATABLE` results.

  If an unsupported combination is requested, a SQLWarning is issued on this Connection and the closest supported combination is used instead.

  Specified by:
    `prepareCall` in interface `Connection`
  Parameters:
    `sql` - a `String` object that is the SQL statement to be sent to the database; may contain on or more '?' parameters
    `resultSetType` - a result set type; one of `ResultSet.TYPE_FORWARD_ONLY`, `ResultSet.TYPE_SCROLL_INSENSITIVE`, or `ResultSet.TYPE_SCROLL_SENSITIVE`
    `resultSetConcurrency` - a concurrency type; one of `ResultSet.CONCUR_READ_ONLY` or `ResultSet.CONCUR_UPDATABLE`
  Returns:
    a new `CallableStatement` object containing the pre-compiled SQL statement that will produce `ResultSet` objects with the given type and concurrency
  Throws:
    `SQLException` - if a database access error occurs, this method (JDBC4 Clarification:) is called on a closed connection (:JDBC4 Clarification) or the given parameters are not `ResultSet` constants indicating type and concurrency
    `SQLFeatureNotSupportedException` - if the JDBC driver does not support this method or this method is not supported for the specified result set type and result set concurrency.
  Since:
    JDK 1.2 (JDK 1.1.x developers: read the overview for JDBCConnection)

### getTypeMap

    public Map<String,Class<?>> getTypeMap()
                                    throws SQLException

  Retrieves the `Map` object associated with this `Connection` object. Unless the application has added an entry, the type map returned will be empty. JDBC 4.1[

  You must invoke `setTypeMap` after making changes to the `Map` object returned from `getTypeMap` as a JDBC driver may create an internal copy of the `Map` object passed to `setTypeMap`:

            Map<String,Class<?>> myMap = con.getTypeMap();
            myMap.put("mySchemaName.ATHLETES", Athletes.class);
            con.setTypeMap(myMap);

  ]

  ### HSQLDB-Specific Information:

  For compatibility, HSQLDB returns an empty map.

  Specified by:
    `getTypeMap` in interface `Connection`
  Returns:
    the `java.util.Map` object associated with this `Connection` object
  Throws:
    `SQLException` - if a database access error occurs (JDBC4 Clarification:) or this method is called on a closed connection
    `SQLFeatureNotSupportedException` - if the JDBC driver does not support this method
  Since:
    JDK 1.2 (JDK 1.1.x developers: read the overview for JDBCConnection)
  See Also:
    `setTypeMap(java.util.Map>)`

### setTypeMap

    public void setTypeMap(Map<String,Class<?>> map)
                    throws SQLException

  Installs the given `TypeMap` object as the type map for this `Connection` object. The type map will be used for the custom mapping of SQL structured types and distinct types. JDBC4.1[

  You must set the the values for the `TypeMap` prior to calling `setMap` as a JDBC driver may create an internal copy of the `TypeMap`:

            Map myMap<String,Class<?>> = new HashMap<String,Class<?>>();
            myMap.put("mySchemaName.ATHLETES", Athletes.class);
            con.setTypeMap(myMap);

  ]

  ### HSQLDB-Specific Information:

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

  Specified by:
    `setTypeMap` in interface `Connection`
  Parameters:
    `map` - the `java.util.Map` object to install as the replacement for this `Connection` object's default type map
  Throws:
    `SQLException` - if a database access error occurs, this (JDBC4 Clarification:) method is called on a closed connection or (:JDBC4 Clarification) the given parameter is not a `java.util.Map` object
    `SQLFeatureNotSupportedException` - if the JDBC driver does not support this method
  Since:
    JDK 1.2 (JDK 1.1.x developers: read the overview for JDBCConnection)
  See Also:
    `getTypeMap()`

### setHoldability

    public void setHoldability(int holdability)
                        throws SQLException

  (JDBC4 Clarification:) Changes the default holdability of `ResultSet` objects created using this `Connection` object to the given holdability. The default holdability of `ResultSet` objects can be be determined by invoking `DatabaseMetaData.getResultSetHoldability()`.

  ### HSQLDB-Specific Information:

  HSQLDB supports this feature.

  Specified by:
    `setHoldability` in interface `Connection`
  Parameters:
    `holdability` - a `ResultSet` holdability constant; one of `ResultSet.HOLD_CURSORS_OVER_COMMIT` or `ResultSet.CLOSE_CURSORS_AT_COMMIT`
  Throws:
    `SQLException` - if a database access occurs, this method is called (JDBC4 Clarification:) on a closed connection, or the given parameter (:JDBC4 Clarification) is not a `ResultSet` constant indicating holdability
    `SQLFeatureNotSupportedException` - if the given holdability is not supported
  Since:
    JDK 1.4, HSQLDB 1.7.2
  See Also:
    `getHoldability()`, `DatabaseMetaData.getResultSetHoldability()`, `JDBCResultSet`

### getHoldability

    public int getHoldability()
                       throws SQLException

  Retrieves the current holdability of `ResultSet` objects created using this `Connection` object.

  ### HSQLDB-Specific Information:

  HSQLDB returns the current holdability.

  The default is HOLD_CURSORS_OVER_COMMIT.

  Specified by:
    `getHoldability` in interface `Connection`
  Returns:
    the holdability, one of `ResultSet.HOLD_CURSORS_OVER_COMMIT` or `ResultSet.CLOSE_CURSORS_AT_COMMIT`
  Throws:
    `SQLException` - if a database access error occurs (JDBC4 Clarification:) or this method is called on a closed connection
  Since:
    JDK 1.4, HSQLDB 1.7.2
  See Also:
    `setHoldability(int)`, `DatabaseMetaData.getResultSetHoldability()`, `JDBCResultSet`

### setSavepoint

    public Savepoint setSavepoint()
                           throws SQLException

  Creates an unnamed savepoint in the current transaction and returns the new `Savepoint` object that represents it.

  (JDBC4 clarification:) if setSavepoint is invoked outside of an active transaction, a transaction will be started at this newly created savepoint.

  ### HSQLDB-Specific Information:

  From 2.0, HSQLDB supports this feature.

  Note: Unnamed savepoints are not part of the SQL:2003 standard. Use setSavepoint(String name) instead.

  Specified by:
    `setSavepoint` in interface `Connection`
  Returns:
    the new `Savepoint` object
  Throws:
    `SQLException` - if a database access error occurs, (JDBC4 Clarification:) this method is called while participating in a distributed transaction, this method is called on a closed connection or this `Connection` object is currently in auto-commit mode
    `SQLFeatureNotSupportedException` - if the JDBC driver does not support this method
  Since:
    JDK 1.4, HSQLDB 1.7.2
  See Also:
    `JDBCSavepoint`, `Savepoint`

### setSavepoint

    public Savepoint setSavepoint(String name)
                           throws SQLException

  Creates a savepoint with the given name in the current transaction and returns the new `Savepoint` object that represents it.

  if setSavepoint is invoked outside of an active transaction, a transaction will be started at this newly created savepoint.

  ### HSQLDB-Specific Information:

  Previous to JDBC 4, if the connection is autoCommit, setting a savepoint has no effect, as it is cleared upon the execution of the next transactional statement. When built for JDBC 4, this method throws an SQLException when this `Connection` object is currently in auto-commit mode, as per the JDBC 4 standard.

  Specified by:
    `setSavepoint` in interface `Connection`
  Parameters:
    `name` - a `String` containing the name of the savepoint
  Returns:
    the new `Savepoint` object
  Throws:
    `SQLException` - if a database access error occurs, (JDBC4 Clarification:) this method is called while participating in a distributed transaction, this method is called on a closed connection or this `Connection` object is currently in auto-commit mode
    `SQLFeatureNotSupportedException` - if the JDBC driver does not support this method
  Since:
    JDK 1.4, HSQLDB 1.7.2
  See Also:
    `JDBCSavepoint`, `Savepoint`

### rollback

    public void rollback(Savepoint savepoint)
                  throws SQLException

  Undoes all changes made after the given `Savepoint` object was set.

  This method should be used only when auto-commit has been disabled.

  ### HSQLDB-Specific Information:

  Previous to JDBC 4, `JDBCSavepoint` objects are valid for the life of the originating `Connection` object and hence can be used interchangeably, as long as they have equal savepoint names.

  When built for JDBC 4, `JDBCConnection` objects invalidate `JDBCSavepoint` objects when auto-commit mode is entered as well as when they are used to successfully release or roll back to a named SQL savepoint. As per the JDBC 4 standard, when built for JDBC 4, this method throws an `SQLException` when this `Connection` object is currently in auto-commit mode and an invalidated `JDBCSavepoint` is specified.

  Specified by:
    `rollback` in interface `Connection`
  Parameters:
    `savepoint` - the `Savepoint` object to roll back to
  Throws:
    `SQLException` - if a database access error occurs, this method is called while participating in a distributed transaction, this method is called on a closed connection, the `Savepoint` object is no longer valid, or this `Connection` object is currently in auto-commit mode
    `SQLFeatureNotSupportedException` - if the JDBC driver does not support this method
  Since:
    JDK 1.4, HSQLDB 1.7.2
  See Also:
    `JDBCSavepoint`, `Savepoint`, `rollback()`

### releaseSavepoint

    public void releaseSavepoint(Savepoint savepoint)
                          throws SQLException

  Removes the specified `Savepoint` (JDBC4 Clarification:) and subsequent `Savepoint` objects from the current transaction. Any reference to the savepoint after it have been removed will cause an `SQLException` to be thrown. HSLQDB Note:

  Previous to JDBC 4, `JDBCSavepoint` objects are valid for the life of the originating `Connection` object and hence can be used interchangeably, as long as they have equal savepoint names.

  When built for JDBC 4, `JDBCConnection` objects invalidate `JDBCSavepoint` objects when auto-commit mode is entered as well as when they are used to successfully release or roll back to a named SQL savepoint. As per the JDBC 4 standard, when built for JDBC 4, this method throws an `SQLException` when this `Connection` object is currently in auto-commit mode and when an invalidated `JDBCSavepoint` is specified.

  Specified by:
    `releaseSavepoint` in interface `Connection`
  Parameters:
    `savepoint` - the `Savepoint` object to be removed
  Throws:
    `SQLException` - if a database access error occurs, this (JDBC4 Clarification:) method is called on a closed connection or the given `Savepoint` object is not a valid savepoint in the current transaction
    `SQLFeatureNotSupportedException` - if the JDBC driver does not support this method
  Since:
    JDK 1.4, HSQLDB 1.7.2
  See Also:
    `JDBCSavepoint`, `Savepoint`

### createStatement

    public Statement createStatement(int resultSetType,
                                     int resultSetConcurrency,
                                     int resultSetHoldability)
                              throws SQLException

  Creates a `Statement` object that will generate `ResultSet` objects with the given type, concurrency, and holdability. This method is the same as the `createStatement` method above, but it allows the default result set type, concurrency, and holdability to be overridden.

  ### HSQLDB-Specific Information:

  HSQLDB 2.0 adheres closely to SQL and JDBC standards. The interpretation of of resultSetType and resultSetConcurrency has changed in this version.

  HSQLDB supports `TYPE_FORWARD_ONLY`, `TYPE_SCROLL_INSENSITIVE`, `CONCUR_READ_ONLY`, `CONCUR_UPDATABLE` results.

  If an unsupported combination is requested, a SQLWarning is issued on this Connection and the closest supported combination is used instead.

  Specified by:
    `createStatement` in interface `Connection`
  Parameters:
    `resultSetType` - one of the following `ResultSet` constants: `ResultSet.TYPE_FORWARD_ONLY`, `ResultSet.TYPE_SCROLL_INSENSITIVE`, or `ResultSet.TYPE_SCROLL_SENSITIVE`
    `resultSetConcurrency` - one of the following `ResultSet` constants: `ResultSet.CONCUR_READ_ONLY` or `ResultSet.CONCUR_UPDATABLE`
    `resultSetHoldability` - one of the following `ResultSet` constants: `ResultSet.HOLD_CURSORS_OVER_COMMIT` or `ResultSet.CLOSE_CURSORS_AT_COMMIT`
  Returns:
    a new `Statement` object that will generate `ResultSet` objects with the given type, concurrency, and holdability
  Throws:
    `SQLException` - if a database access error occurs, this (JDBC4 Clarification:) method is called on a closed connection (:JDBC4 Clarification) or the given parameters are not `ResultSet` constants indicating type, concurrency, and holdability
    `SQLFeatureNotSupportedException` - if the JDBC driver does not support this method or this method is not supported for the specified result set type, result set holdability and result set concurrency.
  Since:
    JDK 1.4, HSQLDB 1.7.2
  See Also:
    `JDBCResultSet`

### prepareStatement

    public PreparedStatement prepareStatement(String sql,
                                              int resultSetType,
                                              int resultSetConcurrency,
                                              int resultSetHoldability)
                                       throws SQLException

  Creates a `PreparedStatement` object that will generate `ResultSet` objects with the given type, concurrency, and holdability.

  This method is the same as the `prepareStatement` method above, but it allows the default result set type, concurrency, and holdability to be overridden.

  ### HSQLDB-Specific Information:

  HSQLDB 2.0 adheres closely to SQL and JDBC standards. The interpretation of of resultSetType and resultSetConcurrency has changed in this version.

  HSQLDB supports `TYPE_FORWARD_ONLY`, `TYPE_SCROLL_INSENSITIVE`, `CONCUR_READ_ONLY`, `CONCUR_UPDATABLE` results.

  `HOLD_CURSORS_OVER_COMMIT` is supported only when `CONCUR_READ_ONLY` is requested.

  If an unsupported combination is requested, a SQLWarning is issued on this Connection and the closest supported combination is used instead.

  Specified by:
    `prepareStatement` in interface `Connection`
  Parameters:
    `sql` - a `String` object that is the SQL statement to be sent to the database; may contain one or more '?' IN parameters
    `resultSetType` - one of the following `ResultSet` constants: `ResultSet.TYPE_FORWARD_ONLY`, `ResultSet.TYPE_SCROLL_INSENSITIVE`, or `ResultSet.TYPE_SCROLL_SENSITIVE`
    `resultSetConcurrency` - one of the following `ResultSet` constants: `ResultSet.CONCUR_READ_ONLY` or `ResultSet.CONCUR_UPDATABLE`
    `resultSetHoldability` - one of the following `ResultSet` constants: `ResultSet.HOLD_CURSORS_OVER_COMMIT` or `ResultSet.CLOSE_CURSORS_AT_COMMIT`
  Returns:
    a new `PreparedStatement` object, containing the pre-compiled SQL statement, that will generate `ResultSet` objects with the given type, concurrency, and holdability
  Throws:
    `SQLException` - if a database access error occurs, this (JDBC4 Clarification:) method is called on a closed connection (:JDBC4 Clarification) or the given parameters are not `ResultSet` constants indicating type, concurrency, and holdability
    `SQLFeatureNotSupportedException` - if the JDBC driver does not support this method or this method is not supported for the specified result set type, result set holdability and result set concurrency.
  Since:
    JDK 1.4, HSQLDB 1.7.2
  See Also:
    `JDBCResultSet`

### prepareCall

    public CallableStatement prepareCall(String sql,
                                         int resultSetType,
                                         int resultSetConcurrency,
                                         int resultSetHoldability)
                                  throws SQLException

  Creates a `CallableStatement` object that will generate `ResultSet` objects with the given type and concurrency. This method is the same as the `prepareCall` method above, but it allows the default result set type, result set concurrency type and holdability to be overridden.

  ### HSQLDB-Specific Information:

  HSQLDB 2.0 adheres closely to SQL and JDBC standards. The interpretation of of resultSetType and resultSetConcurrency has changed in this version.

  HSQLDB supports `TYPE_FORWARD_ONLY`, `TYPE_SCROLL_INSENSITIVE`, `CONCUR_READ_ONLY`, `CONCUR_UPDATABLE` results.

  If an unsupported combination is requested, a SQLWarning is issued on this Connection and the closest supported combination is used instead.

  Specified by:
    `prepareCall` in interface `Connection`
  Parameters:
    `sql` - a `String` object that is the SQL statement to be sent to the database; may contain on or more '?' parameters
    `resultSetType` - one of the following `ResultSet` constants: `ResultSet.TYPE_FORWARD_ONLY`, `ResultSet.TYPE_SCROLL_INSENSITIVE`, or `ResultSet.TYPE_SCROLL_SENSITIVE`
    `resultSetConcurrency` - one of the following `ResultSet` constants: `ResultSet.CONCUR_READ_ONLY` or `ResultSet.CONCUR_UPDATABLE`
    `resultSetHoldability` - one of the following `ResultSet` constants: `ResultSet.HOLD_CURSORS_OVER_COMMIT` or `ResultSet.CLOSE_CURSORS_AT_COMMIT`
  Returns:
    a new `CallableStatement` object, containing the pre-compiled SQL statement, that will generate `ResultSet` objects with the given type, concurrency, and holdability
  Throws:
    `SQLException` - if a database access error occurs, this (JDBC4 Clarification:) method is called on a closed connection (:JDBC4 Clarification) or the given parameters are not `ResultSet` constants indicating type, concurrency, and holdability
    `SQLFeatureNotSupportedException` - if the JDBC driver does not support this method or this method is not supported for the specified result set type, result set holdability and result set concurrency.
  Since:
    JDK 1.4, HSQLDB 1.7.2
  See Also:
    `JDBCResultSet`

### prepareStatement

    public PreparedStatement prepareStatement(String sql,
                                              int autoGeneratedKeys)
                                       throws SQLException

  Creates a default `PreparedStatement` object that has the capability to retrieve auto-generated keys. The given constant tells the driver whether it should make auto-generated keys available for retrieval. This parameter is ignored if the SQL statement is not an `INSERT` statement, or an SQL statement able to return auto-generated keys (the list of such statements is vendor-specific).

  Note: This method is optimized for handling parametric SQL statements that benefit from pre-compilation. If the driver supports pre-compilation, the method `prepareStatement` will send the statement to the database for pre-compilation. Some drivers may not support pre-compilation. In this case, the statement may not be sent to the database until the `PreparedStatement` object is executed. This has no direct effect on users; however, it does affect which methods throw certain SQLExceptions.

  Result sets created using the returned `PreparedStatement` object will by default be type `TYPE_FORWARD_ONLY` and have a concurrency level of `CONCUR_READ_ONLY`. (JDBC4 Clarification:) The holdability of the created result sets can be determined by calling `getHoldability()`.

  ### HSQLDB-Specific Information:

  Starting with version 2.0, HSQLDB supports returning generated columns with single-row and multi-row INSERT, UPDATE and MERGE statements.

  If the table has an IDENTITY or GENERATED column(s) the values for these columns are returned in the next call to getGeneratedKeys() after each execution of the PreparedStatement.

  Specified by:
    `prepareStatement` in interface `Connection`
  Parameters:
    `sql` - an SQL statement that may contain one or more '?' IN parameter placeholders
    `autoGeneratedKeys` - a flag indicating whether auto-generated keys should be returned; one of `Statement.RETURN_GENERATED_KEYS` or `Statement.NO_GENERATED_KEYS`
  Returns:
    a new `PreparedStatement` object, containing the pre-compiled SQL statement, that will have the capability of returning auto-generated keys
  Throws:
    `SQLException` - if a database access error occurs, this (JDBC4 Clarification:) method is called on a closed connection (:JDBC4 Clarification) or the given parameter is not a `Statement` constant indicating whether auto-generated keys should be returned
    `SQLFeatureNotSupportedException` - if the JDBC driver does not support this method with a constant of Statement.RETURN_GENERATED_KEYS
  Since:
    JDK 1.4, HSQLDB 1.7.2

### prepareStatement

    public PreparedStatement prepareStatement(String sql,
                                              int[] columnIndexes)
                                       throws SQLException

  Creates a default `PreparedStatement` object capable of returning the auto-generated keys designated by the given array. This array contains the indexes of the columns in the target table that contain the auto-generated keys that should be made available. The driver will ignore the array if the SQL statement is not an `INSERT` statement, or an SQL statement able to return auto-generated keys (the list of such statements is vendor-specific).

  An SQL statement with or without IN parameters can be pre-compiled and stored in a `PreparedStatement` object. This object can then be used to efficiently execute this statement multiple times.

  Note: This method is optimized for handling parametric SQL statements that benefit from pre-compilation. If the driver supports pre-compilation, the method `prepareStatement` will send the statement to the database for pre-compilation. Some drivers may not support pre-compilation. In this case, the statement may not be sent to the database until the `PreparedStatement` object is executed. This has no direct effect on users; however, it does affect which methods throw certain SQLExceptions.

  Result sets created using the returned `PreparedStatement` object will by default be type `TYPE_FORWARD_ONLY` and have a concurrency level of `CONCUR_READ_ONLY`. (JDBC4 Clarification:) The holdability of the created result sets can be determined by calling `getHoldability()`.

  ### HSQLDB-Specific Information:

  Starting with version 2.0, HSQLDB supports returning generated columns with single-row and multi-row INSERT, UPDATE and MERGE statements.

  The columnIndexes may specify any set of columns of the table.

  Specified by:
    `prepareStatement` in interface `Connection`
  Parameters:
    `sql` - an SQL statement that may contain one or more '?' IN parameter placeholders
    `columnIndexes` - an array of column indexes indicating the columns that should be returned from the inserted row or rows
  Returns:
    a new `PreparedStatement` object, containing the pre-compiled statement, that is capable of returning the auto-generated keys designated by the given array of column indexes
  Throws:
    `SQLException` - if a database access error occurs (JDBC4 Clarification:) or this method is called on a closed connection
    `SQLFeatureNotSupportedException` - if the JDBC driver does not support this method
  Since:
    JDK 1.4, HSQLDB 1.7.2

### prepareStatement

    public PreparedStatement prepareStatement(String sql,
                                              String[] columnNames)
                                       throws SQLException

  Creates a default `PreparedStatement` object capable of returning the auto-generated keys designated by the given array. This array contains the names of the columns in the target table that contain the auto-generated keys that should be returned. The driver will ignore the array if the SQL statement is not an `INSERT` statement, or an SQL statement able to return auto-generated keys (the list of such statements is vendor-specific).

  An SQL statement with or without IN parameters can be pre-compiled and stored in a `PreparedStatement` object. This object can then be used to efficiently execute this statement multiple times.

  Note: This method is optimized for handling parametric SQL statements that benefit from pre-compilation. If the driver supports pre-compilation, the method `prepareStatement` will send the statement to the database for pre-compilation. Some drivers may not support pre-compilation. In this case, the statement may not be sent to the database until the `PreparedStatement` object is executed. This has no direct effect on users; however, it does affect which methods throw certain SQLExceptions.

  Result sets created using the returned `PreparedStatement` object will by default be type `TYPE_FORWARD_ONLY` and have a concurrency level of `CONCUR_READ_ONLY`. (JDBC4 Clarification:) The holdability of the created result sets can be determined by calling `getHoldability()`.

  ### HSQLDB-Specific Information:

  Starting with version 2.0, HSQLDB supports returning generated columns with single-row and multi-row INSERT, UPDATE and MERGE statements.

  The columnNames may specify any set of columns of the table.

  Specified by:
    `prepareStatement` in interface `Connection`
  Parameters:
    `sql` - an SQL statement that may contain one or more '?' IN parameter placeholders
    `columnNames` - an array of column names indicating the columns that should be returned from the inserted row or rows
  Returns:
    a new `PreparedStatement` object, containing the pre-compiled statement, that is capable of returning the auto-generated keys designated by the given array of column names
  Throws:
    `SQLException` - if a database access error occurs (JDBC4 Clarification:) or this method is called on a closed connection
    `SQLFeatureNotSupportedException` - if the JDBC driver does not support this method
  Since:
    JDK 1.4, HSQLDB 1.7.2

### createClob

    public Clob createClob()
                    throws SQLException

  Constructs an object that implements the `Clob` interface. The object returned initially contains no data. The `setAsciiStream`, `setCharacterStream` and `setString` methods of the `Clob` interface may be used to add data to the `Clob`.

  Specified by:
    `createClob` in interface `Connection`
  Returns:
    An object that implements the `Clob` interface
  Throws:
    `SQLException` - if an object that implements the `Clob` interface can not be constructed, this method is called on a closed connection or a database access error occurs.
    `SQLFeatureNotSupportedException` - if the JDBC driver does not support this data type
  Since:
    JDK 1.6, HSQLDB 2.0

### createBlob

    public Blob createBlob()
                    throws SQLException

  Constructs an object that implements the `Blob` interface. The object returned initially contains no data. The `setBinaryStream` and `setBytes` methods of the `Blob` interface may be used to add data to the `Blob`.

  Specified by:
    `createBlob` in interface `Connection`
  Returns:
    An object that implements the `Blob` interface
  Throws:
    `SQLException` - if an object that implements the `Blob` interface can not be constructed, this method is called on a closed connection or a database access error occurs.
    `SQLFeatureNotSupportedException` - if the JDBC driver does not support this data type
  Since:
    JDK 1.6, HSQLDB 2.0

### createNClob

    public NClob createNClob()
                      throws SQLException

  Constructs an object that implements the `NClob` interface. The object returned initially contains no data. The `setAsciiStream`, `setCharacterStream` and `setString` methods of the `NClob` interface may be used to add data to the `NClob`.

  Specified by:
    `createNClob` in interface `Connection`
  Returns:
    An object that implements the `NClob` interface
  Throws:
    `SQLException` - if an object that implements the `NClob` interface can not be constructed, this method is called on a closed connection or a database access error occurs.
    `SQLFeatureNotSupportedException` - if the JDBC driver does not support this data type
  Since:
    JDK 1.6, HSQLDB 2.0

### createSQLXML

    public SQLXML createSQLXML()
                        throws SQLException

  Constructs an object that implements the `SQLXML` interface. The object returned initially contains no data. The `createXmlStreamWriter` object and `setString` method of the `SQLXML` interface may be used to add data to the `SQLXML` object.

  Specified by:
    `createSQLXML` in interface `Connection`
  Returns:
    An object that implements the `SQLXML` interface
  Throws:
    `SQLException` - if an object that implements the `SQLXML` interface can not be constructed, this method is called on a closed connection or a database access error occurs.
    `SQLFeatureNotSupportedException` - if the JDBC driver does not support this data type
  Since:
    JDK 1.6, HSQLDB 2.0

### isValid

    public boolean isValid(int timeout)
                    throws SQLException

  Returns true if the connection has not been closed and is still valid. The driver shall submit a query on the connection or use some other mechanism that positively verifies the connection is still valid when this method is called.

  The query submitted by the driver to validate the connection shall be executed in the context of the current transaction.

  ### HSQLDB-Specific Information:

  HSQLDB uses a maximum timeout of 60 seconds if timeout has be specified as zero.

  Specified by:
    `isValid` in interface `Connection`
  Parameters:
    `timeout` - - The time in seconds to wait for the database operation used to validate the connection to complete. If the timeout period expires before the operation completes, this method returns false. A value of 0 indicates a timeout is not applied to the database operation.

  Returns:
    true if the connection is valid, false otherwise
  Throws:
    `SQLException` - if the value supplied for `timeout` is less then 0
  Since:
    JDK 1.6, HSQLDB 2.0

  See Also:
    `JDBCDatabaseMetaData.getClientInfoProperties()`

### setClientInfo

    public void setClientInfo(String name,
                              String value)
                       throws SQLClientInfoException

  Sets the value of the client info property specified by name to the value specified by value.

  Applications may use the `DatabaseMetaData.getClientInfoProperties` method to determine the client info properties supported by the driver and the maximum length that may be specified for each property.

  The driver stores the value specified in a suitable location in the database. For example in a special register, session parameter, or system table column. For efficiency the driver may defer setting the value in the database until the next time a statement is executed or prepared. Other than storing the client information in the appropriate place in the database, these methods shall not alter the behavior of the connection in anyway. The values supplied to these methods are used for accounting, diagnostics and debugging purposes only.

  The driver shall generate a warning if the client info name specified is not recognized by the driver.

  If the value specified to this method is greater than the maximum length for the property the driver may either truncate the value and generate a warning or generate a `SQLClientInfoException`. If the driver generates a `SQLClientInfoException`, the value specified was not set on the connection.

  The following are standard client info properties. Drivers are not required to support these properties however if the driver supports a client info property that can be described by one of the standard properties, the standard property name should be used.

  - ApplicationName - The name of the application currently utilizing the connection
  - ClientUser - The name of the user that the application using the connection is performing work for. This may not be the same as the user name that was used in establishing the connection.
  - ClientHostname - The host name of the computer the application using the connection is running on.

  ### HSQLDB-Specific Information:

  HSQLDB 2.0, throws an SQLClientInfoException when this method is called.

  Specified by:
    `setClientInfo` in interface `Connection`
  Parameters:
    `name` - The name of the client info property to set
    `value` - The value to set the client info property to. If the value is null, the current value of the specified property is cleared.

  Throws:
    `SQLClientInfoException` - if the database server returns an error while setting the client info value on the database server or this method is called on a closed connection

  Since:
    JDK 1.6, HSQLDB 2.0

### setClientInfo

    public void setClientInfo(Properties properties)
                       throws SQLClientInfoException

  Sets the value of the connection's client info properties. The `Properties` object contains the names and values of the client info properties to be set. The set of client info properties contained in the properties list replaces the current set of client info properties on the connection. If a property that is currently set on the connection is not present in the properties list, that property is cleared. Specifying an empty properties list will clear all of the properties on the connection. See `setClientInfo (String, String)` for more information.

  If an error occurs in setting any of the client info properties, a `SQLClientInfoException` is thrown. The `SQLClientInfoException` contains information indicating which client info properties were not set. The state of the client information is unknown because some databases do not allow multiple client info properties to be set atomically. For those databases, one or more properties may have been set before the error occurred.

  Specified by:
    `setClientInfo` in interface `Connection`
  Parameters:
    `properties` - the list of client info properties to set

  Throws:
    `SQLClientInfoException` - if the database server returns an error while setting the clientInfo values on the database server or this method is called on a closed connection

  Since:
    JDK 1.6, HSQLDB 2.0

  See Also:
    `setClientInfo(String, String)`

### getClientInfo

    public String getClientInfo(String name)
                         throws SQLException

  Returns the value of the client info property specified by name. This method may return null if the specified client info property has not been set and does not have a default value. This method will also return null if the specified client info property name is not supported by the driver.

  Applications may use the `DatabaseMetaData.getClientInfoProperties` method to determine the client info properties supported by the driver.

  Specified by:
    `getClientInfo` in interface `Connection`
  Parameters:
    `name` - The name of the client info property to retrieve

  Returns:
    The value of the client info property specified

  Throws:
    `SQLException` - if the database server returns an error when fetching the client info value from the database or this method is called on a closed connection

  Since:
    JDK 1.6, HSQLDB 2.0

  See Also:
    `DatabaseMetaData.getClientInfoProperties()`

### getClientInfo

    public Properties getClientInfo()
                             throws SQLException

  Returns a list containing the name and current value of each client info property supported by the driver. The value of a client info property may be null if the property has not been set and does not have a default value.

  Specified by:
    `getClientInfo` in interface `Connection`
  Returns:
    A `Properties` object that contains the name and current value of each of the client info properties supported by the driver.

  Throws:
    `SQLException` - if the database server returns an error when fetching the client info values from the database or this method is called on a closed connection

  Since:
    JDK 1.6, HSQLDB 2.0

### createArrayOf

    public Array createArrayOf(String typeName,
                               Object[] elements)
                        throws SQLException

  Factory method for creating Array objects.

  Note: When `createArrayOf` is used to create an array object that maps to a primitive data type, then it is implementation-defined whether the `Array` object is an array of that primitive data type or an array of `Object`.

  Note: The JDBC driver is responsible for mapping the elements `Object` array to the default JDBC SQL type defined in java.sql.Types for the given class of `Object`. The default mapping is specified in Appendix B of the JDBC specification. If the resulting JDBC type is not the appropriate type for the given typeName then it is implementation defined whether an `SQLException` is thrown or the driver supports the resulting conversion.

  Specified by:
    `createArrayOf` in interface `Connection`
  Parameters:
    `typeName` - the SQL name of the type the elements of the array map to. The typeName is a database-specific name which may be the name of a built-in type, a user-defined type or a standard SQL type supported by this database. This is the value returned by `Array.getBaseTypeName`
    `elements` - the elements that populate the returned object
  Returns:
    an Array object whose elements map to the specified SQL type
  Throws:
    `SQLException` - if a database error occurs, the JDBC type is not appropriate for the typeName and the conversion is not supported, the typeName is null or this method is called on a closed connection
    `SQLFeatureNotSupportedException` - if the JDBC driver does not support this data type
  Since:
    1.6

### createStruct

    public Struct createStruct(String typeName,
                               Object[] attributes)
                        throws SQLException

  Factory method for creating Struct objects.

  Specified by:
    `createStruct` in interface `Connection`
  Parameters:
    `typeName` - the SQL type name of the SQL structured type that this `Struct` object maps to. The typeName is the name of a user-defined type that has been defined for this database. It is the value returned by `Struct.getSQLTypeName`.
    `attributes` - the attributes that populate the returned object
  Returns:
    a Struct object that maps to the given SQL type and is populated with the given attributes
  Throws:
    `SQLException` - if a database error occurs, the typeName is null or this method is called on a closed connection
    `SQLFeatureNotSupportedException` - if the JDBC driver does not support this data type
  Since:
    JDK 1.6_b80, HSQLDB 2.0

### unwrap

    public <T> T unwrap(Class<T> iface)
             throws SQLException

  Returns an object that implements the given interface to allow access to non-standard methods, or standard methods not exposed by the proxy. If the receiver implements the interface then the result is the receiver or a proxy for the receiver. If the receiver is a wrapper and the wrapped object implements the interface then the result is the wrapped object or a proxy for the wrapped object. Otherwise return the the result of calling `unwrap` recursively on the wrapped object or a proxy for that result. If the receiver is not a wrapper and does not implement the interface, then an `SQLException` is thrown.

  Specified by:
    `unwrap` in interface `Wrapper`
  Type Parameters:
    `T` - by which the return type is inferred from input parameter.
  Parameters:
    `iface` - A Class defining an interface that the result must implement.
  Returns:
    an object that implements the interface. May be a proxy for the actual implementing object.
  Throws:
    `SQLException` - If no object found that implements the interface
  Since:
    JDK 1.6, HSQLDB 2.0

### isWrapperFor

    public boolean isWrapperFor(Class<?> iface)
                         throws SQLException

  Returns true if this either implements the interface argument or is directly or indirectly a wrapper for an object that does. Returns false otherwise. If this implements the interface then return true, else if this is a wrapper then return the result of recursively calling `isWrapperFor` on the wrapped object. If this does not implement the interface and is not a wrapper, return false. This method should be implemented as a low-cost operation compared to `unwrap` so that callers can use this method to avoid expensive `unwrap` calls that may fail. If this method returns true then calling `unwrap` with the same argument should succeed.

  Specified by:
    `isWrapperFor` in interface `Wrapper`
  Parameters:
    `iface` - a Class defining an interface.
  Returns:
    true if this implements the interface or directly or indirectly wraps an object that does.
  Throws:
    `SQLException` - if an error occurs while determining whether this is a wrapper for an object with the given interface.
  Since:
    JDK 1.6, HSQLDB 2.0

### setSchema

    public void setSchema(String schema)
                   throws SQLException

  Sets the given schema name to access.

  If the driver does not support schemas, it will silently ignore this request.

  Calling `setSchema` has no effect on previously created or prepared `Statement` objects. It is implementation defined whether a DBMS prepare operation takes place immediately when the `Connection` method `prepareStatement` or `prepareCall` is invoked. For maximum portability, `setSchema` should be called before a `Statement` is created or prepared.

  Parameters:
    `schema` - the name of a schema in which to work
  Throws:
    `SQLException` - if a database access error occurs or this method is called on a closed connection
  Since:
    JDK 1.7, HSQLDB 2.0.1
  See Also:
    `getSchema()`

### getSchema

    public String getSchema()
                     throws SQLException

  Retrieves this `Connection` object's current schema name.

  Returns:
    the current schema name or `null` if there is none
  Throws:
    `SQLException` - if a database access error occurs or this method is called on a closed connection
  Since:
    JDK 1.7 M11 2010/09/10 (b123), HSQLDB 2.0.1
  See Also:
    `setSchema(java.lang.String)`

### abort

    public void abort(Executor executor)
               throws SQLException

  Terminates an open connection. Calling `abort` results in:
  - The connection marked as closed
  - Closes any physical connection to the database
  - Releases resources used by the connection
  - Insures that any thread that is currently accessing the connection will either progress to completion or throw an `SQLException`.

  Calling `abort` marks the connection closed and releases any resources. Calling `abort` on a closed connection is a no-op.

  It is possible that the aborting and releasing of the resources that are held by the connection can take an extended period of time. When the `abort` method returns, the connection will have been marked as closed and the `Executor` that was passed as a parameter to abort may still be executing tasks to release resources.

  This method checks to see that there is an `SQLPermission` object before allowing the method to proceed. If a `SecurityManager` exists and its `checkPermission` method denies calling `abort`, this method throws a `java.lang.SecurityException`.

  Parameters:
    `executor` - The `Executor` implementation which will be used by `abort`.
  Throws:
    `SQLException` - if a database access error occurs or the `executor` is `null`,
    `SecurityException` - if a security manager exists and its `checkPermission` method denies calling `abort`
  Since:
    JDK 1.7, HSQLDB 2.0.1
  See Also:
    `SecurityManager.checkPermission(java.security.Permission)`, `Executor`

### setNetworkTimeout

    public void setNetworkTimeout(Executor executor,
                                  int milliseconds)
                           throws SQLException

  Sets the maximum period a `Connection` or objects created from the `Connection` will wait for the database to reply to any one request. If any request remains unanswered, the waiting method will return with a `SQLException`, and the `Connection` or objects created from the `Connection` will be marked as closed. Any subsequent use of the objects, with the exception of the `close`, `isClosed` or `Connection.isValid` methods, will result in a `SQLException`.

  Note: This method is intended to address a rare but serious condition where network partitions can cause threads issuing JDBC calls to hang uninterruptedly in socket reads, until the OS TCP-TIMEOUT (typically 10 minutes). This method is related to the `abort()` method which provides an administrator thread a means to free any such threads in cases where the JDBC connection is accessible to the administrator thread. The `setNetworkTimeout` method will cover cases where there is no administrator thread, or it has no access to the connection. This method is severe in it's effects, and should be given a high enough value so it is never triggered before any more normal timeouts, such as transaction timeouts.

  JDBC driver implementations may also choose to support the `setNetworkTimeout` method to impose a limit on database response time, in environments where no network is present.

  Drivers may internally implement some or all of their API calls with multiple internal driver-database transmissions, and it is left to the driver implementation to determine whether the limit will be applied always to the response to the API call, or to any single request made during the API call.

  This method can be invoked more than once, such as to set a limit for an area of JDBC code, and to reset to the default on exit from this area. Invocation of this method has no impact on already outstanding requests.

  The `Statement.setQueryTimeout()` timeout value is independent of the timeout value specified in `setNetworkTimeout`. If the query timeout expires before the network timeout then the statement execution will be canceled. If the network is still active the result will be that both the statement and connection are still usable. However if the network timeout expires before the query timeout or if the statement timeout fails due to network problems, the connection will be marked as closed, any resources held by the connection will be released and both the connection and statement will be unusable.

  When the driver determines that the `setNetworkTimeout` timeout value has expired, the JDBC driver marks the connection closed and releases any resources held by the connection.

  This method checks to see that there is an `SQLPermission` object before allowing the method to proceed. If a `SecurityManager` exists and its `checkPermission` method denies calling `setNetworkTimeout`, this method throws a `java.lang.SecurityException`.

  Parameters:
    `executor` - The `Executor` implementation which will be used by `setNetworkTimeout`.
    `milliseconds` - The time in milliseconds to wait for the database operation to complete. If the JDBC driver does not support milliseconds, the JDBC driver will round the value up to the nearest second. If the timeout period expires before the operation completes, a SQLException will be thrown. A value of 0 indicates that there is not timeout for database operations.
  Throws:
    `SQLException` - if a database access error occurs, this method is called on a closed connection, the `executor` is `null`, or the value specified for `seconds` is less than 0.
    `SecurityException` - if a security manager exists and its `checkPermission` method denies calling `setNetworkTimeout`.
    `SQLFeatureNotSupportedException` - if the JDBC driver does not support this method
  Since:
    JDK 1.7 M11 2010/09/10 (b123), HSQLDB 2.0.1
  See Also:
    `SecurityManager.checkPermission(java.security.Permission)`, `Statement.setQueryTimeout(int)`, `getNetworkTimeout()`, `abort(java.util.concurrent.Executor)`, `Executor`

### getNetworkTimeout

    public int getNetworkTimeout()
                          throws SQLException

  Retrieves the number of milliseconds the driver will wait for a database request to complete. If the limit is exceeded, a `SQLException` is thrown.

  Returns:
    the current timeout limit in milliseconds; zero means there is no limit
  Throws:
    `SQLException` - if a database access error occurs or this method is called on a closed `Connection`
    `SQLFeatureNotSupportedException` - if the JDBC driver does not support this method
  Since:
    JDK 1.7 M11 2010/09/10 (b123), HSQLDB 2.0.1
  See Also:
    `setNetworkTimeout(java.util.concurrent.Executor, int)`

### reset

    public void reset()
               throws SQLException

  Resets this connection so it can be used again. Used when connections are returned to a connection pool.

  Throws:
    `SQLException` - if a database access error occurs

### closeFully

    public void closeFully()

  Completely closes a pooled connection

### getSession

    public org.hsqldb.SessionInterface getSession()

  provides cross-package access to the proprietary (i.e. non-JDBC) HSQLDB session interface.

  Returns:
    the underlying sessionProxy for this connection

Overview | Package | Class | Use | Tree | Deprecated | Index | Help
PREV CLASS NEXT CLASS | FRAMES NO FRAMES
SUMMARY: NESTED | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD

Copyright © 2001 - 2010 HSQL Development Group.