|
||||||||||
PREV CLASS NEXT CLASS | FRAMES NO FRAMES | |||||||||
SUMMARY: NESTED | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD |
java.lang.Objectorg.hsqldb.jdbc.jdbcDatabaseMetaData
public class jdbcDatabaseMetaData
Path for Ejb3Unit
(fredt@users)
(boucherb@users)
DatabaseInformation
,
DatabaseInformationMain
,
DatabaseInformationFull
Field Summary |
---|
Fields inherited from interface java.sql.DatabaseMetaData |
---|
attributeNoNulls, attributeNullable, attributeNullableUnknown, bestRowNotPseudo, bestRowPseudo, bestRowSession, bestRowTemporary, bestRowTransaction, bestRowUnknown, columnNoNulls, columnNullable, columnNullableUnknown, importedKeyCascade, importedKeyInitiallyDeferred, importedKeyInitiallyImmediate, importedKeyNoAction, importedKeyNotDeferrable, importedKeyRestrict, importedKeySetDefault, importedKeySetNull, procedureColumnIn, procedureColumnInOut, procedureColumnOut, procedureColumnResult, procedureColumnReturn, procedureColumnUnknown, procedureNoNulls, procedureNoResult, procedureNullable, procedureNullableUnknown, procedureResultUnknown, procedureReturnsResult, sqlStateSQL99, sqlStateXOpen, tableIndexClustered, tableIndexHashed, tableIndexOther, tableIndexStatistic, typeNoNulls, typeNullable, typeNullableUnknown, typePredBasic, typePredChar, typePredNone, typeSearchable, versionColumnNotPseudo, versionColumnPseudo, versionColumnUnknown |
Method Summary | |
---|---|
boolean |
allProceduresAreCallable()
Retrieves whether the current user can call all the procedures returned by the method getProcedures . |
boolean |
allTablesAreSelectable()
Retrieves whether the current user can use all the tables returned by the method getTables in a SELECT statement. |
boolean |
dataDefinitionCausesTransactionCommit()
Retrieves whether a data definition statement within a transaction forces the transaction to commit. |
boolean |
dataDefinitionIgnoredInTransactions()
Retrieves whether this database ignores a data definition statement within a transaction. |
boolean |
deletesAreDetected(int type)
Retrieves whether or not a visible row delete can be detected by calling the method ResultSet.rowDeleted . |
boolean |
doesMaxRowSizeIncludeBlobs()
Retrieves whether the return value for the method getMaxRowSize includes the SQL data types
LONGVARCHAR and LONGVARBINARY . |
java.sql.ResultSet |
getAttributes(java.lang.String catalog,
java.lang.String schemaPattern,
java.lang.String typeNamePattern,
java.lang.String attributeNamePattern)
Retrieves a description of the given attribute of the given type for a user-defined type (UDT) that is available in the given schema and catalog. |
java.sql.ResultSet |
getBestRowIdentifier(java.lang.String catalog,
java.lang.String schema,
java.lang.String table,
int scope,
boolean nullable)
Retrieves a description of a table's optimal set of columns that uniquely identifies a row. |
java.sql.ResultSet |
getCatalogs()
Retrieves the catalog names available in this database. |
java.lang.String |
getCatalogSeparator()
Retrieves the String that this database uses as the
separator between a catalog and table name. |
java.lang.String |
getCatalogTerm()
Retrieves the database vendor's preferred term for "catalog". |
java.sql.ResultSet |
getColumnPrivileges(java.lang.String catalog,
java.lang.String schema,
java.lang.String table,
java.lang.String columnNamePattern)
Retrieves a description of the access rights for a table's columns. |
java.sql.ResultSet |
getColumns(java.lang.String catalog,
java.lang.String schemaPattern,
java.lang.String tableNamePattern,
java.lang.String columnNamePattern)
Retrieves a description of table columns available in the specified catalog. |
java.sql.Connection |
getConnection()
Retrieves the connection that produced this metadata object. |
java.sql.ResultSet |
getCrossReference(java.lang.String primaryCatalog,
java.lang.String primarySchema,
java.lang.String primaryTable,
java.lang.String foreignCatalog,
java.lang.String foreignSchema,
java.lang.String foreignTable)
Retrieves a description of the foreign key columns in the given foreign key table that reference the primary key columns of the given primary key table (describe how one table imports another's key). |
int |
getDatabaseMajorVersion()
Retrieves the major version number of the underlying database. |
int |
getDatabaseMinorVersion()
Retrieves the minor version number of the underlying database. |
java.lang.String |
getDatabaseProductName()
Retrieves the name of this database product. |
java.lang.String |
getDatabaseProductVersion()
Retrieves the version number of this database product. |
int |
getDefaultTransactionIsolation()
Retrieves this database's default transaction isolation level. |
int |
getDriverMajorVersion()
Retrieves this JDBC driver's major version number. |
int |
getDriverMinorVersion()
Retrieves this JDBC driver's minor version number. |
java.lang.String |
getDriverName()
Retrieves the name of this JDBC driver. |
java.lang.String |
getDriverVersion()
Retrieves the version number of this JDBC driver as a String . |
java.sql.ResultSet |
getExportedKeys(java.lang.String catalog,
java.lang.String schema,
java.lang.String table)
Retrieves a description of the foreign key columns that reference the given table's primary key columns (the foreign keys exported by a table). |
java.lang.String |
getExtraNameCharacters()
Retrieves all the "extra" characters that can be used in unquoted identifier names (those beyond a-z, A-Z, 0-9 and _). |
java.lang.String |
getIdentifierQuoteString()
Retrieves the string used to quote SQL identifiers. |
java.sql.ResultSet |
getImportedKeys(java.lang.String catalog,
java.lang.String schema,
java.lang.String table)
Retrieves a description of the primary key columns that are referenced by a table's foreign key columns (the primary keys imported by a table). |
java.sql.ResultSet |
getIndexInfo(java.lang.String catalog,
java.lang.String schema,
java.lang.String table,
boolean unique,
boolean approximate)
Retrieves a description of the given table's indices and statistics. |
int |
getJDBCMajorVersion()
Retrieves the major JDBC version number for this driver. |
int |
getJDBCMinorVersion()
Retrieves the minor JDBC version number for this driver. |
int |
getMaxBinaryLiteralLength()
Retrieves the maximum number of hex characters this database allows in an inline binary literal. |
int |
getMaxCatalogNameLength()
Retrieves the maximum number of characters that this database allows in a catalog name. |
int |
getMaxCharLiteralLength()
Retrieves the maximum number of characters this database allows for a character literal. |
int |
getMaxColumnNameLength()
Retrieves the maximum number of characters this database allows for a column name. |
int |
getMaxColumnsInGroupBy()
Retrieves the maximum number of columns this database allows in a GROUP BY clause. |
int |
getMaxColumnsInIndex()
Retrieves the maximum number of columns this database allows in an index. |
int |
getMaxColumnsInOrderBy()
Retrieves the maximum number of columns this database allows in an ORDER BY clause. |
int |
getMaxColumnsInSelect()
Retrieves the maximum number of columns this database allows in a SELECT list. |
int |
getMaxColumnsInTable()
Retrieves the maximum number of columns this database allows in a table. |
int |
getMaxConnections()
Retrieves the maximum number of concurrent connections to this database that are possible. |
int |
getMaxCursorNameLength()
Retrieves the maximum number of characters that this database allows in a cursor name. |
int |
getMaxIndexLength()
Retrieves the maximum number of bytes this database allows for an index, including all of the parts of the index. |
int |
getMaxProcedureNameLength()
Retrieves the maximum number of characters that this database allows in a procedure name. |
int |
getMaxRowSize()
Retrieves the maximum number of bytes this database allows in a single row. |
int |
getMaxSchemaNameLength()
Retrieves the maximum number of characters that this database allows in a schema name. |
int |
getMaxStatementLength()
Retrieves the maximum number of characters this database allows in an SQL statement. |
int |
getMaxStatements()
Retrieves the maximum number of active statements to this database that can be open at the same time. |
int |
getMaxTableNameLength()
Retrieves the maximum number of characters this database allows in a table name. |
int |
getMaxTablesInSelect()
Retrieves the maximum number of tables this database allows in a SELECT statement. |
int |
getMaxUserNameLength()
Retrieves the maximum number of characters this database allows in a user name. |
java.lang.String |
getNumericFunctions()
Retrieves a comma-separated list of math functions available with this database. |
java.sql.ResultSet |
getPrimaryKeys(java.lang.String catalog,
java.lang.String schema,
java.lang.String table)
Retrieves a description of the given table's primary key columns. |
java.sql.ResultSet |
getProcedureColumns(java.lang.String catalog,
java.lang.String schemaPattern,
java.lang.String procedureNamePattern,
java.lang.String columnNamePattern)
Retrieves a description of the given catalog's stored procedure parameter and result columns. |
java.sql.ResultSet |
getProcedures(java.lang.String catalog,
java.lang.String schemaPattern,
java.lang.String procedureNamePattern)
Retrieves a description of the stored procedures available in the given catalog. |
java.lang.String |
getProcedureTerm()
Retrieves the database vendor's preferred term for "procedure". |
int |
getResultSetHoldability()
Retrieves the default holdability of this ResultSet
object. |
java.sql.ResultSet |
getSchemas()
Retrieves the schema names available in this database. |
java.lang.String |
getSchemaTerm()
Retrieves the database vendor's preferred term for "schema". |
java.lang.String |
getSearchStringEscape()
Retrieves the string that can be used to escape wildcard characters. |
java.lang.String |
getSQLKeywords()
Retrieves a comma-separated list of all of this database's SQL keywords that are NOT also SQL92 keywords. |
int |
getSQLStateType()
Indicates whether the SQLSTATEs returned by SQLException.getSQLState is X/Open (now known as Open
Group) SQL CLI or SQL99. |
java.lang.String |
getStringFunctions()
Retrieves a comma-separated list of string functions available with this database. |
java.sql.ResultSet |
getSuperTables(java.lang.String catalog,
java.lang.String schemaPattern,
java.lang.String tableNamePattern)
Retrieves a description of the table hierarchies defined in a particular schema in this database. |
java.sql.ResultSet |
getSuperTypes(java.lang.String catalog,
java.lang.String schemaPattern,
java.lang.String typeNamePattern)
Retrieves a description of the user-defined type (UDT) hierarchies defined in a particular schema in this database. |
java.lang.String |
getSystemFunctions()
Retrieves a comma-separated list of system functions available with this database. |
java.sql.ResultSet |
getTablePrivileges(java.lang.String catalog,
java.lang.String schemaPattern,
java.lang.String tableNamePattern)
Retrieves a description of the access rights for each table available in a catalog. |
java.sql.ResultSet |
getTables(java.lang.String catalog,
java.lang.String schemaPattern,
java.lang.String tableNamePattern,
java.lang.String[] types)
Retrieves a description of the tables available in the given catalog. |
java.sql.ResultSet |
getTableTypes()
Retrieves the table types available in this database. |
java.lang.String |
getTimeDateFunctions()
Retrieves a comma-separated list of the time and date functions available with this database. |
java.sql.ResultSet |
getTypeInfo()
Retrieves a description of all the standard SQL types supported by this database. |
java.sql.ResultSet |
getUDTs(java.lang.String catalog,
java.lang.String schemaPattern,
java.lang.String typeNamePattern,
int[] types)
Retrieves a description of the user-defined types (UDTs) defined in a particular schema. |
java.lang.String |
getURL()
Retrieves the URL for this DBMS. |
java.lang.String |
getUserName()
Retrieves the user name as known to this database. |
java.sql.ResultSet |
getVersionColumns(java.lang.String catalog,
java.lang.String schema,
java.lang.String table)
Retrieves a description of a table's columns that are automatically updated when any value in a row is updated. |
boolean |
insertsAreDetected(int type)
Retrieves whether or not a visible row insert can be detected by calling the method ResultSet.rowInserted . |
boolean |
isCatalogAtStart()
Retrieves whether a catalog appears at the start of a fully qualified table name. |
boolean |
isReadOnly()
Retrieves whether this database is in read-only mode. |
boolean |
locatorsUpdateCopy()
Indicates whether updates made to a LOB are made on a copy or directly to the LOB. |
boolean |
nullPlusNonNullIsNull()
Retrieves whether this database supports concatenations between NULL and non-NULL values being
NULL . |
boolean |
nullsAreSortedAtEnd()
Retrieves whether NULL values are sorted at the end
regardless of sort order. |
boolean |
nullsAreSortedAtStart()
Retrieves whether NULL values are sorted at the start
regardless of sort order. |
boolean |
nullsAreSortedHigh()
Retrieves whether NULL values are sorted high. |
boolean |
nullsAreSortedLow()
Retrieves whether NULL values are sorted low. |
boolean |
othersDeletesAreVisible(int type)
Retrieves whether deletes made by others are visible. |
boolean |
othersInsertsAreVisible(int type)
Retrieves whether inserts made by others are visible. |
boolean |
othersUpdatesAreVisible(int type)
Retrieves whether updates made by others are visible. |
boolean |
ownDeletesAreVisible(int type)
Retrieves whether a result set's own deletes are visible. |
boolean |
ownInsertsAreVisible(int type)
Retrieves whether a result set's own inserts are visible. |
boolean |
ownUpdatesAreVisible(int type)
Retrieves whether for the given type of ResultSet object,
the result set's own updates are visible. |
boolean |
storesLowerCaseIdentifiers()
Retrieves whether this database treats mixed case unquoted SQL identifiers as case insensitive and stores them in lower case. |
boolean |
storesLowerCaseQuotedIdentifiers()
Retrieves whether this database treats mixed case quoted SQL identifiers as case insensitive and stores them in lower case. |
boolean |
storesMixedCaseIdentifiers()
Retrieves whether this database treats mixed case unquoted SQL identifiers as case insensitive and stores them in mixed case. |
boolean |
storesMixedCaseQuotedIdentifiers()
Retrieves whether this database treats mixed case quoted SQL identifiers as case insensitive and stores them in mixed case. |
boolean |
storesUpperCaseIdentifiers()
Retrieves whether this database treats mixed case unquoted SQL identifiers as case insensitive and stores them in upper case. |
boolean |
storesUpperCaseQuotedIdentifiers()
Retrieves whether this database treats mixed case quoted SQL identifiers as case insensitive and stores them in upper case. |
boolean |
supportsAlterTableWithAddColumn()
Retrieves whether this database supports ALTER TABLE with
add column. |
boolean |
supportsAlterTableWithDropColumn()
Retrieves whether this database supports ALTER TABLE with
drop column. |
boolean |
supportsANSI92EntryLevelSQL()
Retrieves whether this database supports the ANSI92 entry level SQL grammar. |
boolean |
supportsANSI92FullSQL()
Retrieves whether this database supports the ANSI92 full SQL grammar supported. |
boolean |
supportsANSI92IntermediateSQL()
Retrieves whether this database supports the ANSI92 intermediate SQL grammar supported. |
boolean |
supportsBatchUpdates()
Retrieves whether this database supports batch updates. |
boolean |
supportsCatalogsInDataManipulation()
Retrieves whether a catalog name can be used in a data manipulation statement. |
boolean |
supportsCatalogsInIndexDefinitions()
Retrieves whether a catalog name can be used in an index definition statement. |
boolean |
supportsCatalogsInPrivilegeDefinitions()
Retrieves whether a catalog name can be used in a privilege definition statement. |
boolean |
supportsCatalogsInProcedureCalls()
Retrieves whether a catalog name can be used in a procedure call statement. |
boolean |
supportsCatalogsInTableDefinitions()
Retrieves whether a catalog name can be used in a table definition statement. |
boolean |
supportsColumnAliasing()
Retrieves whether this database supports column aliasing. |
boolean |
supportsConvert()
Retrieves whether this database supports the CONVERT
function between SQL types. |
boolean |
supportsConvert(int fromType,
int toType)
Retrieves whether this database supports the CONVERT for
two given SQL types. |
boolean |
supportsCoreSQLGrammar()
Retrieves whether this database supports the ODBC Core SQL grammar. |
boolean |
supportsCorrelatedSubqueries()
Retrieves whether this database supports correlated subqueries. |
boolean |
supportsDataDefinitionAndDataManipulationTransactions()
Retrieves whether this database supports both data definition and data manipulation statements within a transaction. |
boolean |
supportsDataManipulationTransactionsOnly()
Retrieves whether this database supports only data manipulation statements within a transaction. |
boolean |
supportsDifferentTableCorrelationNames()
Retrieves whether, when table correlation names are supported, they are restricted to being different from the names of the tables. |
boolean |
supportsExpressionsInOrderBy()
Retrieves whether this database supports expressions in ORDER BY lists. |
boolean |
supportsExtendedSQLGrammar()
Retrieves whether this database supports the ODBC Extended SQL grammar. |
boolean |
supportsFullOuterJoins()
Retrieves whether this database supports full nested outer joins. |
boolean |
supportsGetGeneratedKeys()
Retrieves whether auto-generated keys can be retrieved after a statement has been executed. |
boolean |
supportsGroupBy()
Retrieves whether this database supports some form of GROUP BY clause. |
boolean |
supportsGroupByBeyondSelect()
Retrieves whether this database supports using columns not included in the SELECT statement in a GROUP BY clause
provided that all of the columns in the SELECT statement
are included in the GROUP BY clause. |
boolean |
supportsGroupByUnrelated()
Retrieves whether this database supports using a column that is not in the SELECT statement in a GROUP BY clause. |
boolean |
supportsIntegrityEnhancementFacility()
Retrieves whether this database supports the SQL Integrity Enhancement Facility. |
boolean |
supportsLikeEscapeClause()
Retrieves whether this database supports specifying a LIKE
escape clause. |
boolean |
supportsLimitedOuterJoins()
Retrieves whether this database provides limited support for outer joins. |
boolean |
supportsMinimumSQLGrammar()
Retrieves whether this database supports the ODBC Minimum SQL grammar. |
boolean |
supportsMixedCaseIdentifiers()
Retrieves whether this database treats mixed case unquoted SQL identifiers as case sensitive and as a result stores them in mixed case. |
boolean |
supportsMixedCaseQuotedIdentifiers()
Retrieves whether this database treats mixed case quoted SQL identifiers as case sensitive and as a result stores them in mixed case. |
boolean |
supportsMultipleOpenResults()
Retrieves whether it is possible to have multiple ResultSet
objects returned from a CallableStatement object
simultaneously. |
boolean |
supportsMultipleResultSets()
Retrieves whether this database supports getting multiple ResultSet objects from a single call to the method
execute . |
boolean |
supportsMultipleTransactions()
Retrieves whether this database allows having multiple transactions open at once (on different connections). |
boolean |
supportsNamedParameters()
Retrieves whether this database supports named parameters to callable statements. |
boolean |
supportsNonNullableColumns()
Retrieves whether columns in this database may be defined as non-nullable. |
boolean |
supportsOpenCursorsAcrossCommit()
Retrieves whether this database supports keeping cursors open across commits. |
boolean |
supportsOpenCursorsAcrossRollback()
Retrieves whether this database supports keeping cursors open across rollbacks. |
boolean |
supportsOpenStatementsAcrossCommit()
Retrieves whether this database supports keeping statements open across commits. |
boolean |
supportsOpenStatementsAcrossRollback()
Retrieves whether this database supports keeping statements open across rollbacks. |
boolean |
supportsOrderByUnrelated()
Retrieves whether this database supports using a column that is not in the SELECT statement in an ORDER BY clause. |
boolean |
supportsOuterJoins()
Retrieves whether this database supports some form of outer join. |
boolean |
supportsPositionedDelete()
Retrieves whether this database supports positioned DELETE
statements. |
boolean |
supportsPositionedUpdate()
Retrieves whether this database supports positioned UPDATE
statements. |
boolean |
supportsResultSetConcurrency(int type,
int concurrency)
Retrieves whether this database supports the given concurrency type in combination with the given result set type. |
boolean |
supportsResultSetHoldability(int holdability)
Retrieves whether this database supports the given result set holdability. |
boolean |
supportsResultSetType(int type)
Retrieves whether this database supports the given result set type. |
boolean |
supportsSavepoints()
Retrieves whether this database supports savepoints. |
boolean |
supportsSchemasInDataManipulation()
Retrieves whether a schema name can be used in a data manipulation statement. |
boolean |
supportsSchemasInIndexDefinitions()
Retrieves whether a schema name can be used in an index definition statement. |
boolean |
supportsSchemasInPrivilegeDefinitions()
Retrieves whether a schema name can be used in a privilege definition statement. |
boolean |
supportsSchemasInProcedureCalls()
Retrieves whether a schema name can be used in a procedure call statement. |
boolean |
supportsSchemasInTableDefinitions()
Retrieves whether a schema name can be used in a table definition statement. |
boolean |
supportsSelectForUpdate()
Retrieves whether this database supports SELECT FOR UPDATE
statements. |
boolean |
supportsStatementPooling()
Retrieves whether this database supports statement pooling. |
boolean |
supportsStoredProcedures()
Retrieves whether this database supports stored procedure calls that use the stored procedure escape syntax. |
boolean |
supportsSubqueriesInComparisons()
Retrieves whether this database supports subqueries in comparison expressions. |
boolean |
supportsSubqueriesInExists()
Retrieves whether this database supports subqueries in EXISTS expressions. |
boolean |
supportsSubqueriesInIns()
Retrieves whether this database supports subqueries in IN
statements. |
boolean |
supportsSubqueriesInQuantifieds()
Retrieves whether this database supports subqueries in quantified expressions. |
boolean |
supportsTableCorrelationNames()
Retrieves whether this database supports table correlation names. |
boolean |
supportsTransactionIsolationLevel(int level)
Retrieves whether this database supports the given transaction isolation level. |
boolean |
supportsTransactions()
Retrieves whether this database supports transactions. |
boolean |
supportsUnion()
Retrieves whether this database supports SQL UNION . |
boolean |
supportsUnionAll()
Retrieves whether this database supports SQL UNION ALL . |
boolean |
updatesAreDetected(int type)
Retrieves whether or not a visible row update can be detected by calling the method ResultSet.rowUpdated . |
boolean |
usesLocalFilePerTable()
Retrieves whether this database uses a file for each table. |
boolean |
usesLocalFiles()
Retrieves whether this database stores tables in a local file. |
Methods inherited from class java.lang.Object |
---|
clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait |
Method Detail |
---|
public boolean allProceduresAreCallable() throws java.sql.SQLException
getProcedures
.
Including 1.7.1, HSQLDB does not return any rows from
getProcedures
. However,
allProceduresAreCallable
always returns
true
. This is simply meant to indicate that all users can
call all stored procedures made available by default in a newly created
HSQLDB database.
Since 1.7.2, HSQLDB provides an option to plug in varying degrees of
support. However, this method still always returns
true
.
In a future release, the plugin interface may be modified to allow implementors to report different values here, based on their implementations.
allProceduresAreCallable
in interface java.sql.DatabaseMetaData
true
if so; false
otherwise
java.sql.SQLException
- if a database access error occurspublic boolean allTablesAreSelectable() throws java.sql.SQLException
getTables
in a SELECT
statement.
Including 1.7.1, HSQLDB throws an exception when a non-admin user without
explicit grant of SELECT
on SYSTEM_TABLES
invokes getTables
. Conversely, all admin users have
implict ALL
on all tables. As a comprimise, this method
always returns true
. However, if a non-admin
user is granted SELECT
on SYSTEM_TABLES
,
then it is possible for that user to be denied SELECT
access to some of the tables listed in response to their invoking
getTables
.
Since 1.7.2, there is an option to plug in system table support that provides getTables() results with greater or lesser degrees of detail and accuracy.
Regardless, 1.7.2 reports true
here, always.
Therefore, it is possible that the reported value is not accurate.
Please note that the default 1.7.2 getTables
behaviour is
omit from the list of requested tables only those to which the
invoking user has no access of any kind.
In a future release, the system table producer plugin interface may be modified to allow implementors to report different values here based on their implementatons.
allTablesAreSelectable
in interface java.sql.DatabaseMetaData
true
if so; false
otherwise
java.sql.SQLException
- if a database access error occurspublic java.lang.String getURL() throws java.sql.SQLException
getURL
in interface java.sql.DatabaseMetaData
null
if it cannot be
generated
java.sql.SQLException
- if a database access error occurspublic java.lang.String getUserName() throws java.sql.SQLException
getUserName
in interface java.sql.DatabaseMetaData
java.sql.SQLException
- if a database access error occurspublic boolean isReadOnly() throws java.sql.SQLException
Up to and including 1.7.1, this is a synonym for
jdbcConnection#isReadOnly()
and does not report on the global
read-only state of the database.
Starting with 1.7.2, this behaviour is corrected by issuing an SQL call
to the new Library.isReadOnlyDatabase
method which provides
correct determination of the read-only status for both local and remote
database instances.
isReadOnly
in interface java.sql.DatabaseMetaData
true
if so; false
otherwise
java.sql.SQLException
- if a database access error occurspublic boolean nullsAreSortedHigh() throws java.sql.SQLException
NULL
values are sorted high. Sorted high
means that NULL
values sort higher than any other value in
a domain. In an ascending order, if this method returns true
,
NULL
values will appear at the end. By contrast, the
method nullsAreSortedAtEnd
indicates whether
NULL
values are sorted at the end regardless of sort
order.
HSQLDB sorts null low; this method always returns false
.
nullsAreSortedHigh
in interface java.sql.DatabaseMetaData
true
if so; false
otherwise
java.sql.SQLException
- if a database access error occurspublic boolean nullsAreSortedLow() throws java.sql.SQLException
NULL
values are sorted low. Sorted low
means that NULL
values sort lower than any other value in
a domain. In an ascending order, if this method returns true
,
NULL
values will appear at the beginning. By contrast, the
method nullsAreSortedAtStart
indicates whether
NULL
values are sorted at the beginning regardless of sort
order.
HSQLDB sorts null low; this method always returns true
.
nullsAreSortedLow
in interface java.sql.DatabaseMetaData
true
if so; false
otherwise
java.sql.SQLException
- if a database access error occurspublic boolean nullsAreSortedAtStart() throws java.sql.SQLException
NULL
values are sorted at the start
regardless of sort order.
HSQLDB sorts null low; this method always returns false
.
nullsAreSortedAtStart
in interface java.sql.DatabaseMetaData
true
if so; false
otherwise
java.sql.SQLException
- if a database access error occurspublic boolean nullsAreSortedAtEnd() throws java.sql.SQLException
NULL
values are sorted at the end
regardless of sort order.
HSQLDB sorts null low; this method always returns false
.
nullsAreSortedAtEnd
in interface java.sql.DatabaseMetaData
true
if so; false
otherwise
java.sql.SQLException
- if a database access error occurspublic java.lang.String getDatabaseProductName() throws java.sql.SQLException
Starting with HSQLDB 1.7.2, this value is retrieved through an SQL call
to the new Library.getDatabaseProductName
method which allows
correct determination of the database product name for both local and
remote database instances.
getDatabaseProductName
in interface java.sql.DatabaseMetaData
java.sql.SQLException
- if a database access error occurspublic java.lang.String getDatabaseProductVersion() throws java.sql.SQLException
Starting with HSQLDB 1.7.2, this value is retrieved through an SQL call
to the new Library.getDatabaseProductVersion
method which allows
correct determination of the database product name for both local and
remote database instances.
getDatabaseProductVersion
in interface java.sql.DatabaseMetaData
java.sql.SQLException
- if a database access error occurspublic java.lang.String getDriverName() throws java.sql.SQLException
getDriverName
in interface java.sql.DatabaseMetaData
java.sql.SQLException
- if a database access error occurspublic java.lang.String getDriverVersion() throws java.sql.SQLException
String
.
getDriverVersion
in interface java.sql.DatabaseMetaData
java.sql.SQLException
- if a database access error occurspublic int getDriverMajorVersion()
getDriverMajorVersion
in interface java.sql.DatabaseMetaData
public int getDriverMinorVersion()
getDriverMinorVersion
in interface java.sql.DatabaseMetaData
public boolean usesLocalFiles() throws java.sql.SQLException
From HSQLDB 1.7.2 it is assumed that this refers to data being stored by the JDBC client. This method always returns false.
usesLocalFiles
in interface java.sql.DatabaseMetaData
true
if so; false
otherwise
java.sql.SQLException
- if a database access error occurspublic boolean usesLocalFilePerTable() throws java.sql.SQLException
Up to and including 1.7.2, HSQLDB does not use a file for each table.
This method always returns false
.
usesLocalFilePerTable
in interface java.sql.DatabaseMetaData
true
if this database uses a local file for each
table; false
otherwise
java.sql.SQLException
- if a database access error occurspublic boolean supportsMixedCaseIdentifiers() throws java.sql.SQLException
HSQLDB treats unquoted identifiers as case insensitive and stores them in
upper case. It treats quoted identifiers as case sensitive and stores
them verbatim; this method always returns false
.
supportsMixedCaseIdentifiers
in interface java.sql.DatabaseMetaData
true
if so; false
otherwise
java.sql.SQLException
- if a database access error occurspublic boolean storesUpperCaseIdentifiers() throws java.sql.SQLException
HSQLDB treats unquoted identifiers as case insensitive and stores them in
upper case. It treats quoted identifiers as case sensitive and stores
them verbatim; this method always returns true
.
storesUpperCaseIdentifiers
in interface java.sql.DatabaseMetaData
true
if so; false
otherwise
java.sql.SQLException
- if a database access error occurspublic boolean storesLowerCaseIdentifiers() throws java.sql.SQLException
HSQLDB treats unquoted identifiers as case insensitive and stores them in
upper case. It treats quoted identifiers as case sensitive and stores
them verbatim; this method always returns false
.
storesLowerCaseIdentifiers
in interface java.sql.DatabaseMetaData
true
if so; false
otherwise
java.sql.SQLException
- if a database access error occurspublic boolean storesMixedCaseIdentifiers() throws java.sql.SQLException
HSQLDB treats unquoted identifiers as case insensitive and stores them in
upper case. It treats quoted identifiers as case sensitive and stores
them verbatim; this method always returns false
.
storesMixedCaseIdentifiers
in interface java.sql.DatabaseMetaData
true
if so; false
otherwise
java.sql.SQLException
- if a database access error occurspublic boolean supportsMixedCaseQuotedIdentifiers() throws java.sql.SQLException
HSQLDB treats unquoted identifiers as case insensitive and stores them in
upper case. It treats quoted identifiers as case sensitive and stores
them verbatim; this method always returns true
.
supportsMixedCaseQuotedIdentifiers
in interface java.sql.DatabaseMetaData
true
if so; false
otherwise
java.sql.SQLException
- if a database access error occurspublic boolean storesUpperCaseQuotedIdentifiers() throws java.sql.SQLException
HSQLDB treats unquoted identifiers as case insensitive and stores them in
upper case. It treats quoted identifiers as case sensitive and stores
them verbatim; this method always returns false
.
storesUpperCaseQuotedIdentifiers
in interface java.sql.DatabaseMetaData
true
if so; false
otherwise
java.sql.SQLException
- if a database access error occurspublic boolean storesLowerCaseQuotedIdentifiers() throws java.sql.SQLException
HSQLDB treats unquoted identifiers as case insensitive and stores them in
upper case. It treats quoted identifiers as case sensitive and stores
them verbatim; this method always returns false
.
storesLowerCaseQuotedIdentifiers
in interface java.sql.DatabaseMetaData
true
if so; false
otherwise
java.sql.SQLException
- if a database access error occurspublic boolean storesMixedCaseQuotedIdentifiers() throws java.sql.SQLException
HSQLDB treats unquoted identifiers as case insensitive and stores them in
upper case. It treats quoted identifiers as case sensitive and stores
them verbatim; this method always returns false
.
storesMixedCaseQuotedIdentifiers
in interface java.sql.DatabaseMetaData
true
if so; false
otherwise
java.sql.SQLException
- if a database access error occurspublic java.lang.String getIdentifierQuoteString() throws java.sql.SQLException
HSQLDB uses the standard SQL identifier quote character (the double quote character); this method always returns ".
getIdentifierQuoteString
in interface java.sql.DatabaseMetaData
java.sql.SQLException
- if a database access error occurspublic java.lang.String getSQLKeywords() throws java.sql.SQLException
The list returned contains HSQLDB keywords that are not in the list of reserved words. Some of these are in the list of potential reserved words that are not SQL92 keywords, but are reported in the standard as possible future SQL keywords.
getSQLKeywords
in interface java.sql.DatabaseMetaData
java.sql.SQLException
- if a database access error occurspublic java.lang.String getNumericFunctions() throws java.sql.SQLException
getNumericFunctions
in interface java.sql.DatabaseMetaData
java.sql.SQLException
- if a database access error occurspublic java.lang.String getStringFunctions() throws java.sql.SQLException
getStringFunctions
in interface java.sql.DatabaseMetaData
java.sql.SQLException
- if a database access error occurspublic java.lang.String getSystemFunctions() throws java.sql.SQLException
getSystemFunctions
in interface java.sql.DatabaseMetaData
java.sql.SQLException
- if a database access error occurspublic java.lang.String getTimeDateFunctions() throws java.sql.SQLException
getTimeDateFunctions
in interface java.sql.DatabaseMetaData
java.sql.SQLException
- if a database access error occurspublic java.lang.String getSearchStringEscape() throws java.sql.SQLException
The '_' character represents any single character; the '%' character represents any sequence of zero or more characters.
HSQLDB uses the "\" character to escape wildcard characters.
getSearchStringEscape
in interface java.sql.DatabaseMetaData
java.sql.SQLException
- if a database access error occurspublic java.lang.String getExtraNameCharacters() throws java.sql.SQLException
HSQLDB does not support using any "extra" characters in unquoted identifier names; this method always returns the empty String.
getExtraNameCharacters
in interface java.sql.DatabaseMetaData
java.sql.SQLException
- if a database access error occurspublic boolean supportsAlterTableWithAddColumn() throws java.sql.SQLException
ALTER TABLE
with
add column.
From 1.7.0, HSQLDB supports this type of ALTER TABLE
statement; this method always returns true
.
supportsAlterTableWithAddColumn
in interface java.sql.DatabaseMetaData
true
if so; false
otherwise
java.sql.SQLException
- if a database access error occurspublic boolean supportsAlterTableWithDropColumn() throws java.sql.SQLException
ALTER TABLE
with
drop column.
From 1.7.0, HSQLDB supports this type of ALTER TABLE
statement; this method always returns true
.
supportsAlterTableWithDropColumn
in interface java.sql.DatabaseMetaData
true
if so; false
otherwise
java.sql.SQLException
- if a database access error occurspublic boolean supportsColumnAliasing() throws java.sql.SQLException
If so, the SQL AS clause can be used to provide names for computed columns or to provide alias names for columns as required.
HSQLDB supports column aliasing; this method always returns
true
.
supportsColumnAliasing
in interface java.sql.DatabaseMetaData
true
if so; false
otherwise
java.sql.SQLException
- if a database access error occurspublic boolean nullPlusNonNullIsNull() throws java.sql.SQLException
NULL
and non-NULL
values being
NULL
.
HSQLDB supports this; this method always returns true
.
nullPlusNonNullIsNull
in interface java.sql.DatabaseMetaData
true
if so; false
otherwise
java.sql.SQLException
- if a database access error occurspublic boolean supportsConvert() throws java.sql.SQLException
CONVERT
function between SQL types.
HSQLDB supports conversions; this method always returns true
.
supportsConvert
in interface java.sql.DatabaseMetaData
true
if so; false
otherwise
java.sql.SQLException
- if a database access error occurspublic boolean supportsConvert(int fromType, int toType) throws java.sql.SQLException
CONVERT
for
two given SQL types.
HSQLDB supports conversion though String intermediates, so everything
should be possible, short of number format errors (all Java objects have
a toString method); this method always returns true
.
supportsConvert
in interface java.sql.DatabaseMetaData
fromType
- the type to convert from; one of the type codes from the class
java.sql.Types
toType
- the type to convert to; one of the type codes from the class
java.sql.Types
true
if so; false
otherwise
java.sql.SQLException
- if a database access error occursTypes
public boolean supportsTableCorrelationNames() throws java.sql.SQLException
HSQLDB supports table correlation names; this method always returns
true
.
supportsTableCorrelationNames
in interface java.sql.DatabaseMetaData
true
if so; false
otherwise
java.sql.SQLException
- if a database access error occurspublic boolean supportsDifferentTableCorrelationNames() throws java.sql.SQLException
HSQLDB requires that table correlation names are different from the names
of the tables; this method always returns true
.
supportsDifferentTableCorrelationNames
in interface java.sql.DatabaseMetaData
true
if so; false
otherwise
java.sql.SQLException
- if a database access error occurspublic boolean supportsExpressionsInOrderBy() throws java.sql.SQLException
ORDER BY
lists.
HSQLDB supports expressions in ORDER BY
lists; this method
always returns true
.
supportsExpressionsInOrderBy
in interface java.sql.DatabaseMetaData
true
if so; false
otherwise
java.sql.SQLException
- if a database access error occurspublic boolean supportsOrderByUnrelated() throws java.sql.SQLException
SELECT
statement in an ORDER BY
clause.
HSQLDB supports using a column that is not in the SELECT
statement in an ORDER BY
clause; this method always
returns true
.
supportsOrderByUnrelated
in interface java.sql.DatabaseMetaData
true
if so; false
otherwise
java.sql.SQLException
- if a database access error occurspublic boolean supportsGroupBy() throws java.sql.SQLException
GROUP BY
clause.
HSQLDB supports using the GROUP BY
clause; this method
always returns true
.
supportsGroupBy
in interface java.sql.DatabaseMetaData
true
if so; false
otherwise
java.sql.SQLException
- if a database access error occurspublic boolean supportsGroupByUnrelated() throws java.sql.SQLException
SELECT
statement in a GROUP BY
clause.
HSQLDB supports using a column that is not in the SELECT
statement in a GROUP BY
clause; this method always returns
true
.
supportsGroupByUnrelated
in interface java.sql.DatabaseMetaData
true
if so; false
otherwise
java.sql.SQLException
- if a database access error occurspublic boolean supportsGroupByBeyondSelect() throws java.sql.SQLException
SELECT
statement in a GROUP BY
clause
provided that all of the columns in the SELECT
statement
are included in the GROUP BY
clause.
HSQLDB supports using columns not included in the SELECT
statement in a GROUP BY
clause provided that all of the
columns in the SELECT
statement are included in the
GROUP BY
clause; this method always returns
true
.
supportsGroupByBeyondSelect
in interface java.sql.DatabaseMetaData
true
if so; false
otherwise
java.sql.SQLException
- if a database access error occurspublic boolean supportsLikeEscapeClause() throws java.sql.SQLException
LIKE
escape clause.
HSQLDB supports specifying a LIKE
escape clause; this
method always returns true
.
supportsLikeEscapeClause
in interface java.sql.DatabaseMetaData
true
if so; false
otherwise
java.sql.SQLException
- if a database access error occurspublic boolean supportsMultipleResultSets() throws java.sql.SQLException
ResultSet
objects from a single call to the method
execute
.
Up to and including 1.7.2, HSQLDB does not support getting multiple
ResultSet
objects from a single call to the method
execute
; this method always returns false
.
This behaviour may change in a future release.
supportsMultipleResultSets
in interface java.sql.DatabaseMetaData
true
if so; false
otherwise
java.sql.SQLException
- if a database access error occurspublic boolean supportsMultipleTransactions() throws java.sql.SQLException
HSQLDB allows having multiple transactions open at once (on different
connections); this method always returns true
.
supportsMultipleTransactions
in interface java.sql.DatabaseMetaData
true
if so; false
otherwise
java.sql.SQLException
- if a database access error occurspublic boolean supportsNonNullableColumns() throws java.sql.SQLException
HSQLDB supports the specification of non-nullable columns; this method
always returns true
.
supportsNonNullableColumns
in interface java.sql.DatabaseMetaData
true
if so; false
otherwise
java.sql.SQLException
- if a database access error occurspublic boolean supportsMinimumSQLGrammar() throws java.sql.SQLException
Up to and including 1.7.2, HSQLDB does not support the ODBC Minimum SQL
grammar; this method always returns false
.
supportsMinimumSQLGrammar
in interface java.sql.DatabaseMetaData
true
if so; false
otherwise
java.sql.SQLException
- if a database access error occurspublic boolean supportsCoreSQLGrammar() throws java.sql.SQLException
From 1.7.2 this method always returns true
.
supportsCoreSQLGrammar
in interface java.sql.DatabaseMetaData
true
if so; false
otherwise
java.sql.SQLException
- if a database access error occurspublic boolean supportsExtendedSQLGrammar() throws java.sql.SQLException
Up to and including 1.7.2, HSQLDB does not support the ODBC Extended SQL
grammar; this method always returns false
.
supportsExtendedSQLGrammar
in interface java.sql.DatabaseMetaData
true
if so; false
otherwise
java.sql.SQLException
- if a database access error occurspublic boolean supportsANSI92EntryLevelSQL() throws java.sql.SQLException
Up to and including 1.7.2, HSQLDB does not support the ANSI92 entry level
SQL grammar; this method always returns false
.
supportsANSI92EntryLevelSQL
in interface java.sql.DatabaseMetaData
true
if so; false
otherwise
java.sql.SQLException
- if a database access error occurspublic boolean supportsANSI92IntermediateSQL() throws java.sql.SQLException
Up to and including 1.7.2, HSQLDB does not support the ANSI92
intermediate SQL grammar; this method always returns false
.
supportsANSI92IntermediateSQL
in interface java.sql.DatabaseMetaData
true
if so; false
otherwise
java.sql.SQLException
- if a database access error occurspublic boolean supportsANSI92FullSQL() throws java.sql.SQLException
Up to and including 1.7.2, HSQLDB does not support the ANSI92 full SQL
grammar; this method always returns false
.
supportsANSI92FullSQL
in interface java.sql.DatabaseMetaData
true
if so; false
otherwise
java.sql.SQLException
- if a database access error occurspublic boolean supportsIntegrityEnhancementFacility() throws java.sql.SQLException
From 1.7.2, this method always returns true
.
supportsIntegrityEnhancementFacility
in interface java.sql.DatabaseMetaData
true
if so; false
otherwise
java.sql.SQLException
- if a database access error occurspublic boolean supportsOuterJoins() throws java.sql.SQLException
HSQLDB supports outer joins; this method always returns true
.
supportsOuterJoins
in interface java.sql.DatabaseMetaData
true
if so; false
otherwise
java.sql.SQLException
- if a database access error occurspublic boolean supportsFullOuterJoins() throws java.sql.SQLException
Up to and including 1.7.2, HSQLDB does not support full nested outer
joins; this method always returns false
.
This behaviour may change in a future release.
supportsFullOuterJoins
in interface java.sql.DatabaseMetaData
true
if so; false
otherwise
java.sql.SQLException
- if a database access error occurspublic boolean supportsLimitedOuterJoins() throws java.sql.SQLException
true
if the method
supportsFullOuterJoins
returns true
).
Up to and including 1.7.2, HSQLDB support the LEFT OUTER join syntax;
this method always returns true
.
supportsLimitedOuterJoins
in interface java.sql.DatabaseMetaData
true
if so; false
otherwise
java.sql.SQLException
- if a database access error occurspublic java.lang.String getSchemaTerm() throws java.sql.SQLException
Up to and including 1.7.1, HSQLDB does not support schemas; this method always returns the empty String.
Starting with 1.7.2, HSQLDB provides an option to plug in support for
different metadata implementations. Using the default
DatabaseInformationFull
plugin, schema support is turned
off by default, but there is an option to turn on support for SQL92-like
schema reporting (system objects such as system tables and built-in
routines are reported in a schema named "DEFINITION_SCHEMA" while user
objects such as regular tables and views are reported in a schema named
"PUBLIC"). However, this feature is experimental and there is still no
support for creating or dropping schemas, choosing the schema in which to
create other database objects or really any other support beyond schema
qualification for table ALTER/DROP DDL and SELECT tables lists. As such,
this method still returns the empty String.
getSchemaTerm
in interface java.sql.DatabaseMetaData
java.sql.SQLException
- if a database access error occurspublic java.lang.String getProcedureTerm() throws java.sql.SQLException
Up to and including 1.7.2, HSQLDB does not support declaration of
functions or procedures directly in SQL but instead relies on the
HSQLDB-specific CLASS grant mechanism to make public static Java methods
available as SQL routines; this method always returns an empty
String
.
getProcedureTerm
in interface java.sql.DatabaseMetaData
java.sql.SQLException
- if a database access error occurspublic java.lang.String getCatalogTerm() throws java.sql.SQLException
Including 1.7.2, HSQLDB does not support catalogs in DDL or DML; this
method
getCatalogTerm
in interface java.sql.DatabaseMetaData
java.sql.SQLException
- if a database access error occurspublic boolean isCatalogAtStart() throws java.sql.SQLException
Up to and including 1.7.2, HSQLDB does not support catalogs in DDL or
DML; this method always returns false
.
isCatalogAtStart
in interface java.sql.DatabaseMetaData
true
if the catalog name appears at the beginning
of a fully qualified table name; false
otherwise
java.sql.SQLException
- if a database access error occurspublic java.lang.String getCatalogSeparator() throws java.sql.SQLException
String
that this database uses as the
separator between a catalog and table name.
Including 1.7.2, HSQLDB does not support catalogs in DDL or DML; this
method always returns an empty String
.
getCatalogSeparator
in interface java.sql.DatabaseMetaData
java.sql.SQLException
- if a database access error occurspublic boolean supportsSchemasInDataManipulation() throws java.sql.SQLException
Up to and including 1.7.1, HSQLDB does not support schemas; this method
always returns false
.
Starting with 1.7.2, HSQLDB provides an option to plug in support for
different metadata implementations. Using the default
DatabaseInformationFull
plugin, schema support is turned
off by default, but there is an option to turn on SQL92-like schema
reporting (system objects such as system tables and built-in routines are
reported in a schema named "DEFINITION_SCHEMA" while user objects such as
regular tables and views are reported in a schema named "PUBLIC."
However, this feature is experimental and there is still no support for
creating or dropping schemas, choosing the schema in which to create
other database objects or really any other support beyond schema
qualification for table ALTER/DROP DDL and SELECT tables lists. As such,
this method still returns false
.
In the a future release, it is intended to provide core support for schema-qualified table and column identifiers, at which point this method will always return true.
supportsSchemasInDataManipulation
in interface java.sql.DatabaseMetaData
true
if so; false
otherwise
java.sql.SQLException
- if a database access error occurspublic boolean supportsSchemasInProcedureCalls() throws java.sql.SQLException
Up to and including 1.7.2, HSQLDB does not support schema-qualified
procedure identifiers; this method always returns false
.
supportsSchemasInProcedureCalls
in interface java.sql.DatabaseMetaData
true
if so; false
otherwise
java.sql.SQLException
- if a database access error occurspublic boolean supportsSchemasInTableDefinitions() throws java.sql.SQLException
Up to and including 1.7.2, HSQLDB does not support schema-qualified table
definitions; this method always returns false
.
supportsSchemasInTableDefinitions
in interface java.sql.DatabaseMetaData
true
if so; false
otherwise
java.sql.SQLException
- if a database access error occurspublic boolean supportsSchemasInIndexDefinitions() throws java.sql.SQLException
Up to and including 1.7.2, HSQLDB does not support schema-qualified index
definitions; this method always returns false
.
supportsSchemasInIndexDefinitions
in interface java.sql.DatabaseMetaData
true
if so; false
otherwise
java.sql.SQLException
- if a database access error occurspublic boolean supportsSchemasInPrivilegeDefinitions() throws java.sql.SQLException
Up to and including 1.7.2, HSQLDB does not support schema-qualified
privilege definitions; this method always returns false
.
supportsSchemasInPrivilegeDefinitions
in interface java.sql.DatabaseMetaData
true
if so; false
otherwise
java.sql.SQLException
- if a database access error occurspublic boolean supportsCatalogsInDataManipulation() throws java.sql.SQLException
Up to and including 1.7.2, HSQLDB does not support catalog-qualified;
data manipulation; this method always returns false
.
supportsCatalogsInDataManipulation
in interface java.sql.DatabaseMetaData
true
if so; false
otherwise
java.sql.SQLException
- if a database access error occurspublic boolean supportsCatalogsInProcedureCalls() throws java.sql.SQLException
Up to and including 1.7.2, HSQLDB does not support catalog-qualified
procedure calls; this method always returns false
.
supportsCatalogsInProcedureCalls
in interface java.sql.DatabaseMetaData
true
if so; false
otherwise
java.sql.SQLException
- if a database access error occurspublic boolean supportsCatalogsInTableDefinitions() throws java.sql.SQLException
Up to and including 1.7.2, HSQLDB does not support catalog-qualified
table definitions; this method always returns false
.
supportsCatalogsInTableDefinitions
in interface java.sql.DatabaseMetaData
true
if so; false
otherwise
java.sql.SQLException
- if a database access error occurspublic boolean supportsCatalogsInIndexDefinitions() throws java.sql.SQLException
Up to and including 1.7.2, HSQLDB does not support catalog-qualified
index definitions; this method always returns false
.
supportsCatalogsInIndexDefinitions
in interface java.sql.DatabaseMetaData
true
if so; false
otherwise
java.sql.SQLException
- if a database access error occurspublic boolean supportsCatalogsInPrivilegeDefinitions() throws java.sql.SQLException
Up to and including 1.7.2, HSQLDB does not support catalog-qualified
privilege definitions; this method always returns false
.
supportsCatalogsInPrivilegeDefinitions
in interface java.sql.DatabaseMetaData
true
if so; false
otherwise
java.sql.SQLException
- if a database access error occurspublic boolean supportsPositionedDelete() throws java.sql.SQLException
DELETE
statements.
Up to and including 1.7.2, HSQLDB does not support updateable result
sets; this method always returns false
.
Starting with 1.8.0, HSQLDB supports updateable result sets.
TODO: Finalize this specification.
supportsPositionedDelete
in interface java.sql.DatabaseMetaData
true
if so; false
otherwise
java.sql.SQLException
- if a database access error occurspublic boolean supportsPositionedUpdate() throws java.sql.SQLException
UPDATE
statements.
Up to and including 1.7.2, HSQLDB does not support updateable result
sets; this method always returns false
.
Starting with 1.8.0, HSQLDB supports updateable result sets.
TODO: Finalize this specification.
supportsPositionedUpdate
in interface java.sql.DatabaseMetaData
true
if so; false
otherwise
java.sql.SQLException
- if a database access error occurspublic boolean supportsSelectForUpdate() throws java.sql.SQLException
SELECT FOR UPDATE
statements.
Up to and including 1.7.2, HSQLDB does not support explicit locking; this
method always returns false
.
Starting with 1.8.0, HSQLDB supports updateable result sets.
TODO: Finalize this specification.
supportsSelectForUpdate
in interface java.sql.DatabaseMetaData
true
if so; false
otherwise
java.sql.SQLException
- if a database access error occurspublic boolean supportsStoredProcedures() throws java.sql.SQLException
Up to and including 1.7.2, HSQLDB supports calling public static Java
methods in the context of SQL Stored Procedures; this method always
returns true
.
supportsStoredProcedures
in interface java.sql.DatabaseMetaData
true
if so; false
otherwise
java.sql.SQLException
- if a database access error occursjdbcPreparedStatement
,
jdbcConnection#prepareCall
public boolean supportsSubqueriesInComparisons() throws java.sql.SQLException
HSQLDB has always supported subqueries in comparison expressions; this
method always returns true
.
supportsSubqueriesInComparisons
in interface java.sql.DatabaseMetaData
true
if so; false
otherwise
java.sql.SQLException
- if a database access error occurspublic boolean supportsSubqueriesInExists() throws java.sql.SQLException
EXISTS
expressions.
HSQLDB has always supported subqueries in EXISTS
expressions; this method always returns true
.
supportsSubqueriesInExists
in interface java.sql.DatabaseMetaData
true
if so; false
otherwise
java.sql.SQLException
- if a database access error occurspublic boolean supportsSubqueriesInIns() throws java.sql.SQLException
IN
statements.
HSQLDB has always supported subqueries in IN
statements;
this method always returns true
.
supportsSubqueriesInIns
in interface java.sql.DatabaseMetaData
true
if so; false
otherwise
java.sql.SQLException
- if a database access error occurspublic boolean supportsSubqueriesInQuantifieds() throws java.sql.SQLException
HSQLDB has always supported subqueries in quantified expressions; this
method always returns true
.
supportsSubqueriesInQuantifieds
in interface java.sql.DatabaseMetaData
true
if so; false
otherwise
java.sql.SQLException
- if a database access error occurspublic boolean supportsCorrelatedSubqueries() throws java.sql.SQLException
HSQLDB has always supported correlated subqueries; this method always
returns true
.
supportsCorrelatedSubqueries
in interface java.sql.DatabaseMetaData
true
if so; false
otherwise
java.sql.SQLException
- if a database access error occurspublic boolean supportsUnion() throws java.sql.SQLException
UNION
.
HSQLDB supports SQL UNION
; this method always returns
true
.
supportsUnion
in interface java.sql.DatabaseMetaData
true
if so; false
otherwise
java.sql.SQLException
- if a database access error occurspublic boolean supportsUnionAll() throws java.sql.SQLException
UNION ALL
.
HSQLDB supports SQL UNION ALL
; this method always returns
true
.
supportsUnionAll
in interface java.sql.DatabaseMetaData
true
if so; false
otherwise
java.sql.SQLException
- if a database access error occurspublic boolean supportsOpenCursorsAcrossCommit() throws java.sql.SQLException
Up to and including 1.7.2, HSQLDB does not support keeping cursors open
across commits; this method always returns false
.
supportsOpenCursorsAcrossCommit
in interface java.sql.DatabaseMetaData
true
if cursors always remain open;
false
if they might not remain open
java.sql.SQLException
- if a database access error occurspublic boolean supportsOpenCursorsAcrossRollback() throws java.sql.SQLException
Up to and including 1.7.2, HSQLDB does not support keeping cursors open
across rollbacks; this method always returns false
.
supportsOpenCursorsAcrossRollback
in interface java.sql.DatabaseMetaData
true
if cursors always remain open;
false
if they might not remain open
java.sql.SQLException
- if a database access error occurspublic boolean supportsOpenStatementsAcrossCommit() throws java.sql.SQLException
HSQLDB supports keeping statements open across commits; this method
always returns true
.
supportsOpenStatementsAcrossCommit
in interface java.sql.DatabaseMetaData
true
if statements always remain open;
false
if they might not remain open
java.sql.SQLException
- if a database access error occurspublic boolean supportsOpenStatementsAcrossRollback() throws java.sql.SQLException
HSQLDB supports keeping statements open across commits; this method
always returns true
.
supportsOpenStatementsAcrossRollback
in interface java.sql.DatabaseMetaData
true
if statements always remain open;
false
if they might not remain open
java.sql.SQLException
- if a database access error occurspublic int getMaxBinaryLiteralLength() throws java.sql.SQLException
HSQLDB does not impose a "known" limit. The hard limit is the maximum
length of a java.lang.String (java.lang.Integer.MAX_VALUE); this method
always returns 0
.
getMaxBinaryLiteralLength
in interface java.sql.DatabaseMetaData
java.sql.SQLException
- if a database access error occurspublic int getMaxCharLiteralLength() throws java.sql.SQLException
HSQLDB does not impose a "known" limit. The hard limit is the maximum
length of a java.lang.String (java.lang.Integer.MAX_VALUE); this method
always returns 0
.
getMaxCharLiteralLength
in interface java.sql.DatabaseMetaData
java.sql.SQLException
- if a database access error occurspublic int getMaxColumnNameLength() throws java.sql.SQLException
HSQLDB does not impose a "known" limit. The hard limit is the maximum
length of a java.lang.String (java.lang.Integer.MAX_VALUE); this method
always returns 0
.
getMaxColumnNameLength
in interface java.sql.DatabaseMetaData
java.sql.SQLException
- if a database access error occurspublic int getMaxColumnsInGroupBy() throws java.sql.SQLException
GROUP BY
clause.
HSQLDB does not impose a "known" limit. The hard limit is the maximum
length of a Java array (java.lang.Integer.MAX_VALUE); this method always
returns 0
.
getMaxColumnsInGroupBy
in interface java.sql.DatabaseMetaData
java.sql.SQLException
- if a database access error occurspublic int getMaxColumnsInIndex() throws java.sql.SQLException
HSQLDB does not impose a "known" limit. The hard limit is the maximum
length of a Java array (java.lang.Integer.MAX_VALUE); this method always
returns 0
.
getMaxColumnsInIndex
in interface java.sql.DatabaseMetaData
java.sql.SQLException
- if a database access error occurspublic int getMaxColumnsInOrderBy() throws java.sql.SQLException
ORDER BY
clause.
HSQLDB does not impose a "known" limit. The hard limit is the maximum
length of a Java array (java.lang.Integer.MAX_VALUE); this method always
returns 0
.
getMaxColumnsInOrderBy
in interface java.sql.DatabaseMetaData
java.sql.SQLException
- if a database access error occurspublic int getMaxColumnsInSelect() throws java.sql.SQLException
SELECT
list.
HSQLDB does not impose a "known" limit. The hard limit is the maximum
length of a Java array (java.lang.Integer.MAX_VALUE); this method always
returns 0
.
getMaxColumnsInSelect
in interface java.sql.DatabaseMetaData
java.sql.SQLException
- if a database access error occurspublic int getMaxColumnsInTable() throws java.sql.SQLException
HSQLDB does not impose a "known" limit. The hard limit is the maximum
length of a Java array (java.lang.Integer.MAX_VALUE); this method always
returns 0
.
getMaxColumnsInTable
in interface java.sql.DatabaseMetaData
java.sql.SQLException
- if a database access error occurspublic int getMaxConnections() throws java.sql.SQLException
HSQLDB does not impose a "known" limit. The hard limit is the maximum
length of a Java array (java.lang.Integer.MAX_VALUE); this method always
returns 0
.
getMaxConnections
in interface java.sql.DatabaseMetaData
java.sql.SQLException
- if a database access error occurspublic int getMaxCursorNameLength() throws java.sql.SQLException
HSQLDB does not impose a "known" limit. The hard limit is the maximum
length of a java.lang.String (java.lang.Integer.MAX_VALUE); this method
always returns 0
.
getMaxCursorNameLength
in interface java.sql.DatabaseMetaData
java.sql.SQLException
- if a database access error occurspublic int getMaxIndexLength() throws java.sql.SQLException
HSQLDB does not impose a "known" limit; this method always returns
0
.
getMaxIndexLength
in interface java.sql.DatabaseMetaData
java.sql.SQLException
- if a database access error occurspublic int getMaxSchemaNameLength() throws java.sql.SQLException
Up to and including 1.7.1, HSQLDB does not support schema names at all.
Starting with 1.7.2, there is a switchable option to support
experimental, limited use of schema names; in any case, no known limit is
imposed, so this method always returns 0
.
getMaxSchemaNameLength
in interface java.sql.DatabaseMetaData
java.sql.SQLException
- if a database access error occurspublic int getMaxProcedureNameLength() throws java.sql.SQLException
HSQLDB does not impose a "known" limit. The hard limit is the maximum
length of a java.lang.String (java.lang.Integer.MAX_VALUE); this method
always returns 0
.
getMaxProcedureNameLength
in interface java.sql.DatabaseMetaData
java.sql.SQLException
- if a database access error occurspublic int getMaxCatalogNameLength() throws java.sql.SQLException
Up to and including 1.7.2, HSQLDB does not support catalogs in DDL or
DML; this method always returns 0
.
getMaxCatalogNameLength
in interface java.sql.DatabaseMetaData
java.sql.SQLException
- if a database access error occurspublic int getMaxRowSize() throws java.sql.SQLException
HSQLDB does not impose a "known" limit; this method always returns
0
.
getMaxRowSize
in interface java.sql.DatabaseMetaData
java.sql.SQLException
- if a database access error occurspublic boolean doesMaxRowSizeIncludeBlobs() throws java.sql.SQLException
getMaxRowSize
includes the SQL data types
LONGVARCHAR
and LONGVARBINARY
.
Including 1.7.2, getMaxRowSize()
always returns 0,
indicating that the maximum row size is unknown or has no limit. This
applies to the above types as well; this method always returns
true
.
doesMaxRowSizeIncludeBlobs
in interface java.sql.DatabaseMetaData
true
if so; false
otherwise
java.sql.SQLException
- if a database access error occurspublic int getMaxStatementLength() throws java.sql.SQLException
HSQLDB does not impose a "known" limit. The hard limit is the maximum
length of a java.lang.String (java.lang.Integer.MAX_VALUE); this method
always returns 0
.
getMaxStatementLength
in interface java.sql.DatabaseMetaData
java.sql.SQLException
- if a database access error occurspublic int getMaxStatements() throws java.sql.SQLException
HSQLDB does not impose a "known" limit; this method always returns
0
.
getMaxStatements
in interface java.sql.DatabaseMetaData
java.sql.SQLException
- if a database access error occurspublic int getMaxTableNameLength() throws java.sql.SQLException
HSQLDB does not impose a "known" limit. The hard limit is the maximum
length of a java.lang.String (java.lang.Integer.MAX_VALUE); this method
always returns 0
.
getMaxTableNameLength
in interface java.sql.DatabaseMetaData
java.sql.SQLException
- if a database access error occurspublic int getMaxTablesInSelect() throws java.sql.SQLException
SELECT
statement.
HSQLDB does not impose a "known" limit. The hard limit is the maximum
length of a Java array (java.lang.Integer.MAX_VALUE); this method always
returns 0
.
getMaxTablesInSelect
in interface java.sql.DatabaseMetaData
SELECT
statement; a result of zero means that there is no limit or the
limit is not known
java.sql.SQLException
- if a database access error occurspublic int getMaxUserNameLength() throws java.sql.SQLException
HSQLDB does not impose a "known" limit. The hard limit is the maximum
length of a java.lang.String (java.lang.Integer.MAX_VALUE); this method
always returns 0
.
getMaxUserNameLength
in interface java.sql.DatabaseMetaData
java.sql.SQLException
- if a database access error occurspublic int getDefaultTransactionIsolation() throws java.sql.SQLException
java.sql.Connection
.
getDefaultTransactionIsolation
in interface java.sql.DatabaseMetaData
java.sql.SQLException
- if a database access error occursjdbcConnection
public boolean supportsTransactions() throws java.sql.SQLException
commit
is a noop, and the isolation level is
TRANSACTION_NONE
.
HSQLDB supports transactions; this method always returns
true
.
supportsTransactions
in interface java.sql.DatabaseMetaData
true
if transactions are supported;
false
otherwise
java.sql.SQLException
- if a database access error occurspublic boolean supportsTransactionIsolationLevel(int level) throws java.sql.SQLException
TRANSACTION_READ_UNCOMMITED
.
supportsTransactionIsolationLevel
in interface java.sql.DatabaseMetaData
level
- one of the transaction isolation levels defined in
java.sql.Connection
true
if so; false
otherwise
java.sql.SQLException
- if a database access error occursjdbcConnection
public boolean supportsDataDefinitionAndDataManipulationTransactions() throws java.sql.SQLException
HSQLDB does not support a mix of both data definition and data
manipulation statements within a transaction. DDL commits the current
transaction before proceding; this method always returns
false
.
supportsDataDefinitionAndDataManipulationTransactions
in interface java.sql.DatabaseMetaData
true
if so; false
otherwise
java.sql.SQLException
- if a database access error occurspublic boolean supportsDataManipulationTransactionsOnly() throws java.sql.SQLException
HSQLDB supports only data manipulation statements within a transaction.
DDL commits the current transaction before proceeding, while DML does
not; this method always returns true
.
supportsDataManipulationTransactionsOnly
in interface java.sql.DatabaseMetaData
true
if so; false
otherwise
java.sql.SQLException
- if a database access error occurspublic boolean dataDefinitionCausesTransactionCommit() throws java.sql.SQLException
Including 1.7.2, a data definition statement within a transaction forces
the transaction to commit; this method always returns true
.
dataDefinitionCausesTransactionCommit
in interface java.sql.DatabaseMetaData
true
if so; false
otherwise
java.sql.SQLException
- if a database access error occurspublic boolean dataDefinitionIgnoredInTransactions() throws java.sql.SQLException
Including 1.7.2, a data definition statement is not ignored within a
transaction. Rather, a data definition statement within a transaction
forces the transaction to commit; this method always returns
false
.
dataDefinitionIgnoredInTransactions
in interface java.sql.DatabaseMetaData
true
if so; false
otherwise
java.sql.SQLException
- if a database access error occurspublic java.sql.ResultSet getProcedures(java.lang.String catalog, java.lang.String schemaPattern, java.lang.String procedureNamePattern) throws java.sql.SQLException
Only procedure descriptions matching the schema and procedure name
criteria are returned. They are ordered by PROCEDURE_SCHEM
and PROCEDURE_NAME
.
Each procedure description has the the following columns:
null
)
null
)
HSQLDB treats unquoted identifiers as case insensitive in SQL but stores them in upper case; it treats quoted identifiers as case sensitive and stores them verbatim. All jdbcDatabaseMetaData methods perform case-sensitive comparison between name (pattern) arguments and the corresponding identifier values as they are stored in the database. Therefore, care must be taken to specify name arguments precisely (including case) as they are stored in the database.
Including 1.7.1, HSQLDB produces an empty result, despite the fact that
stored procedures are available. Also, the three "reserved for future
use" columns in the result are labeled NUM_INPUT_PARAMS,
NUM_OUTPUT_PARAMS, NUM_RESULT_SETS in anticipation of future improvements
(scheduled for 1.7.2).
Since 1.7.2, there is an option to support this feature to greater or
lesser degrees. See the documentation specific to the selected system
table provider implementation. The default implementation is
DatabaseInformationFull
.
getProcedures
in interface java.sql.DatabaseMetaData
catalog
- a catalog name; must match the catalog name as it is stored in
the database; "" retrieves those without a catalog;
null
means that the catalog name should not be
used to narrow the searchschemaPattern
- a schema name pattern; must match the schema name as it is
stored in the database; "" retrieves those without a schema;
null
means that the schema name should not be
used to narrow the searchprocedureNamePattern
- a procedure name pattern; must match the procedure name as it
is stored in the database
ResultSet
- each row is a procedure description
java.sql.SQLException
- if a database access error occursgetSearchStringEscape()
public java.sql.ResultSet getProcedureColumns(java.lang.String catalog, java.lang.String schemaPattern, java.lang.String procedureNamePattern, java.lang.String columnNamePattern) throws java.sql.SQLException
Only descriptions matching the schema, procedure and parameter name criteria are returned. They are ordered by PROCEDURE_SCHEM and PROCEDURE_NAME. Within this, the return value, if any, is first. Next are the parameter descriptions in call order. The column descriptions follow in column number order.
Each row in the ResultSet
is a parameter description or
column description with the following fields:
null
)
null
)
ResultSet
Note: Some databases may not return the column descriptions for a procedure. Additional columns beyond REMARKS can be defined by the database.
HSQLDB treats unquoted identifiers as case insensitive in SQL but stores them in upper case; it treats quoted identifiers as case sensitive and stores them verbatim. All jdbcDatabaseMetaData methods perform case-sensitive comparison between name (pattern) arguments and the corresponding identifier values as they are stored in the database. Therefore, care must be taken to specify name arguments precisely (including case) as they are stored in the database.
Including 1.7.1, HSQLDB produces an empty result, despite the fact that stored procedures are available.
Since 1.7.2, there is an option to support this feature to greater or
lesser degrees. See the documentation specific to the selected system
table provider implementation. The default implementation is
DatabaseInformationFull
.
getProcedureColumns
in interface java.sql.DatabaseMetaData
catalog
- a catalog name; must match the catalog name as it is stored in
the database; "" retrieves those without a catalog;
null
means that the catalog name should not be
used to narrow the searchschemaPattern
- a schema name pattern; must match the schema name as it is
stored in the database; "" retrieves those without a schema;
null
means that the schema name should not be
used to narrow the searchprocedureNamePattern
- a procedure name pattern; must match the procedure name as it
is stored in the databasecolumnNamePattern
- a column name pattern; must match the column name as it is
stored in the database
ResultSet
- each row describes a stored procedure
parameter or column
java.sql.SQLException
- if a database access error occursgetSearchStringEscape()
public java.sql.ResultSet getTables(java.lang.String catalog, java.lang.String schemaPattern, java.lang.String tableNamePattern, java.lang.String[] types) throws java.sql.SQLException
Each table description has the following columns:
null
)
null
)
null
)
null
)
null
)
null
)
null
)
Note: Some databases may not return information for all tables.
HSQLDB treats unquoted identifiers as case insensitive in SQL but stores them in upper case; it treats quoted identifiers as case sensitive and stores them verbatim. All jdbcDatabaseMetaData methods perform case-sensitive comparison between name (pattern) arguments and the corresponding identifier values as they are stored in the database. Therefore, care must be taken to specify name arguments precisely (including case) as they are stored in the database.
Since 1.7.0, HSQLDB returns extra information on TEXT tables in the REMARKS column.
Since 1.7.0, HSQLDB includes the new JDBC3 columns TYPE_CAT, TYPE_SCHEM, TYPE_NAME and SELF_REFERENCING_COL_NAME in anticipation of JDBC3 compliant tools.
Since 1.7.2, there is an option to support this feature to greater or
lesser degrees. See the documentation specific to the selected system
table provider implementation. The default implementation is
DatabaseInformationFull
.
getTables
in interface java.sql.DatabaseMetaData
catalog
- a catalog name; must match the catalog name as it is stored in
the database; "" retrieves those without a catalog;
null
means that the catalog name should not be
used to narrow the searchschemaPattern
- a schema name pattern; must match the schema name as it is
stored in the database; "" retrieves those without a schema;
null
means that the schema name should not be
used to narrow the searchtableNamePattern
- a table name pattern; must match the table name as it is
stored in the databasetypes
- a list of table types to include; null
returns
all types
ResultSet
- each row is a table description
java.sql.SQLException
- if a database access error occursgetSearchStringEscape()
public java.sql.ResultSet getSchemas() throws java.sql.SQLException
The schema column is:
null
)
Since 1.7.0, HSQLDB includes the new JDBC3 column TABLE_CATALOG in anticipation of JDBC3 compliant tools. However, 1.70. does not support schemas and catalogs, so this method always returns an empty result.
Since 1.7.2, there is an option to support this feature to greater or
lesser degrees. See the documentation specific to the selected system
table provider implementation. The default implementation is
DatabaseInformationFull
.
getSchemas
in interface java.sql.DatabaseMetaData
ResultSet
object in which each row is a schema
decription
java.sql.SQLException
- if a database access error occurspublic java.sql.ResultSet getCatalogs() throws java.sql.SQLException
The catalog column is:
Including 1.7.1, HSQLDB does not support catalogs; this method always returns an empty result.
Since 1.7.2, there is an option to support this feature to greater or
lesser degrees. See the documentation specific to the selected system
table provider implementation. The default implementation is
DatabaseInformationFull
.
getCatalogs
in interface java.sql.DatabaseMetaData
ResultSet
object in which each row has a single
String
column that is a catalog name
java.sql.SQLException
- if a database access error occurspublic java.sql.ResultSet getTableTypes() throws java.sql.SQLException
The table type is:
Since 1.7.1, HSQLDB reports: "TABLE", "VIEW" and "GLOBAL TEMPORARY"
types.
Since 1.7.2, there is an option to support this feature to greater or
lesser degrees. See the documentation specific to the selected system
table provider implementation. The default implementation is
DatabaseInformationFull
.
getTableTypes
in interface java.sql.DatabaseMetaData
ResultSet
object in which each row has a single
String
column that is a table type
java.sql.SQLException
- if a database access error occurspublic java.sql.ResultSet getColumns(java.lang.String catalog, java.lang.String schemaPattern, java.lang.String tableNamePattern, java.lang.String columnNamePattern) throws java.sql.SQLException
Only column descriptions matching the catalog, schema, table and column
name criteria are returned. They are ordered by TABLE_SCHEM
,
TABLE_NAME
, and ORDINAL_POSITION
.
Each column description has the following columns:
null
)
null
)
NULL
values
NULL
values
null
)
null
)
null
if DATA_TYPE isn't REF)
null
if the DATA_TYPE isn't REF)
null
if the DATA_TYPE isn't REF)
null
if DATA_TYPE isn't DISTINCT or user-generated REF)
HSQLDB treats unquoted identifiers as case insensitive in SQL but stores them in upper case; it treats quoted identifiers as case sensitive and stores them verbatim. All jdbcDatabaseMetaData methods perform case-sensitive comparison between name (pattern) arguments and the corresponding identifier values as they are stored in the database. Therefore, care must be taken to specify name arguments precisely (including case) as they are stored in the database.
Since 1.7.0, HSQLDB includes the new JDBC 3 columns SCOPE_CATLOG, SCOPE_SCHEMA, SCOPE_TABLE and SOURCE_DATA_TYPE in anticipation of JDBC 3 compliant tools. However, these columns are never filled in; the engine does not support the related features.
Since 1.7.2, there is an option to support this feature to greater or
lesser degrees. See the documentation specific to the selected system
table provider implementation. The default implementation is
DatabaseInformationFull
.
getColumns
in interface java.sql.DatabaseMetaData
catalog
- a catalog name; must match the catalog name as it is stored in
the database; "" retrieves those without a catalog;
null
means that the catalog name should not be
used to narrow the searchschemaPattern
- a schema name pattern; must match the schema name as it is
stored in the database; "" retrieves those without a schema;
null
means that the schema name should not be
used to narrow the searchtableNamePattern
- a table name pattern; must match the table name as it is
stored in the databasecolumnNamePattern
- a column name pattern; must match the column name as it is
stored in the database
ResultSet
- each row is a column description
java.sql.SQLException
- if a database access error occursgetSearchStringEscape()
public java.sql.ResultSet getColumnPrivileges(java.lang.String catalog, java.lang.String schema, java.lang.String table, java.lang.String columnNamePattern) throws java.sql.SQLException
Only privileges matching the column name criteria are returned. They are ordered by COLUMN_NAME and PRIVILEGE.
Each privilige description has the following columns:
null
)
null
)
null
)
null
if unknown
HSQLDB treats unquoted identifiers as case insensitive in SQL but stores them in upper case; it treats quoted identifiers as case sensitive and stores them verbatim. All jdbcDatabaseMetaData methods perform case-sensitive comparison between name (pattern) arguments and the corresponding identifier values as they are stored in the database. Therefore, care must be taken to specify name arguments precisely (including case) as they are stored in the database.
Including 1.7.1, HSQLDB produces an empty result, despite the fact that it is possible to specify DML privileges. However, column-level privileges are not supported; if column privileges were reported, they would be the privileges inherited from each column's table.
Since 1.7.2, there is an option to support this feature to greater or
lesser degrees. See the documentation specific to the selected system
table provider implementation. The default implementation is
DatabaseInformationFull
.
getColumnPrivileges
in interface java.sql.DatabaseMetaData
catalog
- a catalog name; must match the catalog name as it is stored in
the database; "" retrieves those without a catalog;
null
means that the catalog name should not be
used to narrow the searchschema
- a schema name; must match the schema name as it is stored in
the database; "" retrieves those without a schema;
null
means that the schema name should not be
used to narrow the searchtable
- a table name; must match the table name as it is stored in the
databasecolumnNamePattern
- a column name pattern; must match the column name as it is
stored in the database
ResultSet
- each row is a column privilege
description
java.sql.SQLException
- if a database access error occursgetSearchStringEscape()
public java.sql.ResultSet getTablePrivileges(java.lang.String catalog, java.lang.String schemaPattern, java.lang.String tableNamePattern) throws java.sql.SQLException
Only privileges matching the schema and table name criteria are returned. They are ordered by TABLE_SCHEM, TABLE_NAME, and PRIVILEGE.
Each privilige description has the following columns:
null
)
null
)
null
)
null
if unknown
HSQLDB treats unquoted identifiers as case insensitive in SQL but stores them in upper case; it treats quoted identifiers as case sensitive and stores them verbatim. All jdbcDatabaseMetaData methods perform case-sensitive comparison between name (pattern) arguments and the corresponding identifier values as they are stored in the database. Therefore, care must be taken to specify name arguments precisely (including case) as they are stored in the database.
Including 1.7.1, HSQLDB produces an incomplete and possibly incorrect result: for each table, it lists the user "sa" as the grantor, rather than the grantee, and lists IS_GRANTABLE as YES for each row. It does not list rights for any other users. Since the "sa" user can be dropped from the database and recreated as a non-admin user, this result is not only incomplete, it is potentially icorrect.
Since 1.7.2, there is an option to support this feature to greater or
lesser degrees. See the documentation specific to the selected system
table provider implementation. The default implementation is
DatabaseInformationFull
.
getTablePrivileges
in interface java.sql.DatabaseMetaData
catalog
- a catalog name; must match the catalog name as it is stored in
the database; "" retrieves those without a catalog;
null
means that the catalog name should not be
used to narrow the searchschemaPattern
- a schema name pattern; must match the schema name as it is
stored in the database; "" retrieves those without a schema;
null
means that the schema name should not be
used to narrow the searchtableNamePattern
- a table name pattern; must match the table name as it is
stored in the database
ResultSet
- each row is a table privilege
description
java.sql.SQLException
- if a database access error occursgetSearchStringEscape()
public java.sql.ResultSet getBestRowIdentifier(java.lang.String catalog, java.lang.String schema, java.lang.String table, int scope, boolean nullable) throws java.sql.SQLException
Each column description has the following columns:
HSQLDB treats unquoted identifiers as case insensitive in SQL but stores them in upper case; it treats quoted identifiers as case sensitive and stores them verbatim. All jdbcDatabaseMetaData methods perform case-sensitive comparison between name (pattern) arguments and the corresponding identifier values as they are stored in the database. Therefore, care must be taken to specify name arguments precisely (including case) as they are stored in the database.
Including 1.7.1, HSQLDB returns the columns for a user-defined primary
key or unique index if one exists. Otherwise it returns an empty result;
scope
and nullable
parameters are not taken
into account.
If the name of a column is defined in the database without double quotes, an all-uppercase name must be specified when calling this method. Otherwise, the name must be specified in the exact case of the column definition in the database.
Since 1.7.2, there is an option to support this feature to greater or
lesser degrees. See the documentation specific to the selected system
table provider implementation. The default implementation is
DatabaseInformationFull
.
getBestRowIdentifier
in interface java.sql.DatabaseMetaData
catalog
- a catalog name; must match the catalog name as it is stored in
the database; "" retrieves those without a catalog;
null
means that the catalog name should not be
used to narrow the searchschema
- a schema name; must match the schema name as it is stored in
the database; "" retrieves those without a schema;
null
means that the schema name should not be
used to narrow the searchtable
- a table name; must match the table name as it is stored in the
databasescope
- the scope of interest; use same values as SCOPEnullable
- include columns that are nullable.
ResultSet
- each row is a column description
java.sql.SQLException
- if a database access error occurspublic java.sql.ResultSet getVersionColumns(java.lang.String catalog, java.lang.String schema, java.lang.String table) throws java.sql.SQLException
Each column description has the following columns:
java.sql.Types
HSQLDB treats unquoted identifiers as case insensitive in SQL but stores them in upper case; it treats quoted identifiers as case sensitive and stores them verbatim. All jdbcDatabaseMetaData methods perform case-sensitive comparison between name (pattern) arguments and the corresponding identifier values as they are stored in the database. Therefore, care must be taken to specify name arguments precisely (including case) as they are stored in the database.
Including 1.7.1, HSQLDB produces an empty result; no columns are automatically updated when any value in a row changes.
Since 1.7.2, there is an option to support this feature to greater or
lesser degrees. See the documentation specific to the selected system
table provider implementation. The default implementation is
DatabaseInformationFull
.
getVersionColumns
in interface java.sql.DatabaseMetaData
catalog
- a catalog name; must match the catalog name as it is stored in
the database; "" retrieves those without a catalog;
null
means that the catalog name should not be
used to narrow the searchschema
- a schema name; must match the schema name as it is stored in
the database; "" retrieves those without a schema;
null
means that the schema name should not be
used to narrow the searchtable
- a table name; must match the table name as it is stored in the
database
ResultSet
object in which each row is a column
description
java.sql.SQLException
- if a database access error occurspublic java.sql.ResultSet getPrimaryKeys(java.lang.String catalog, java.lang.String schema, java.lang.String table) throws java.sql.SQLException
Each primary key column description has the following columns:
null
)
null
)
null
)
HSQLDB treats unquoted identifiers as case insensitive in SQL but stores them in upper case; it treats quoted identifiers as case sensitive and stores them verbatim. All jdbcDatabaseMetaData methods perform case-sensitive comparison between name (pattern) arguments and the corresponding identifier values as they are stored in the database. Therefore, care must be taken to specify name arguments precisely (including case) as they are stored in the database.
Since 1.7.2, there is an option to support this feature to greater or
lesser degrees. See the documentation specific to the selected system
table provider implementation. The default implementation is
DatabaseInformationFull
.
getPrimaryKeys
in interface java.sql.DatabaseMetaData
catalog
- a catalog name; must match the catalog name as it is stored in
the database; "" retrieves those without a catalog;
null
means that the catalog name should not be
used to narrow the searchschema
- a schema name; must match the schema name as it is stored in
the database; "" retrieves those without a schema;
null
means that the schema name should not be
used to narrow the searchtable
- a table name; must match the table name as it is stored in the
database
ResultSet
- each row is a primary key column
description
java.sql.SQLException
- if a database access error occurssupportsMixedCaseQuotedIdentifiers()
,
storesUpperCaseIdentifiers()
public java.sql.ResultSet getImportedKeys(java.lang.String catalog, java.lang.String schema, java.lang.String table) throws java.sql.SQLException
Each primary key column description has the following columns:
null
)
null
)
null
)
null
)
NULL
if
its primary key has been updated
null
)
null
)
HSQLDB treats unquoted identifiers as case insensitive in SQL but stores them in upper case; it treats quoted identifiers as case sensitive and stores them verbatim. All jdbcDatabaseMetaData methods perform case-sensitive comparison between name (pattern) arguments and the corresponding identifier values as they are stored in the database. Therefore, care must be taken to specify name arguments precisely (including case) as they are stored in the database.
Since 1.7.2, there is an option to support this feature to greater or
lesser degrees. See the documentation specific to the selected system
table provider implementation. The default implementation is
DatabaseInformationFull
.
getImportedKeys
in interface java.sql.DatabaseMetaData
catalog
- a catalog name; must match the catalog name as it is stored in
the database; "" retrieves those without a catalog;
null
means that the catalog name should not be
used to narrow the searchschema
- a schema name; must match the schema name as it is stored in
the database; "" retrieves those without a schema;
null
means that the schema name should not be
used to narrow the searchtable
- a table name; must match the table name as it is stored in the
database
ResultSet
- each row is a primary key column
description
java.sql.SQLException
- if a database access error occursgetExportedKeys(java.lang.String, java.lang.String, java.lang.String)
,
supportsMixedCaseQuotedIdentifiers()
,
storesUpperCaseIdentifiers()
public java.sql.ResultSet getExportedKeys(java.lang.String catalog, java.lang.String schema, java.lang.String table) throws java.sql.SQLException
Each foreign key column description has the following columns:
null
)
null
)
null
) being exported (may be null
)
null
) being exported (may be null
)
NULL
if
its primary key has been updated
NULL
if
its primary key has been deleted
null
)
null
)
HSQLDB treats unquoted identifiers as case insensitive in SQL but stores them in upper case; it treats quoted identifiers as case sensitive and stores them verbatim. All jdbcDatabaseMetaData methods perform case-sensitive comparison between name (pattern) arguments and the corresponding identifier values as they are stored in the database. Therefore, care must be taken to specify name arguments precisely (including case) as they are stored in the database.
Since 1.7.2, there is an option to support this feature to greater or
lesser degrees. See the documentation specific to the selected system
table provider implementation. The default implementation is
DatabaseInformationFull
.
getExportedKeys
in interface java.sql.DatabaseMetaData
catalog
- a catalog name; must match the catalog name as it is stored in
this database; "" retrieves those without a catalog;
null
means that the catalog name should not be
used to narrow the searchschema
- a schema name; must match the schema name as it is stored in
the database; "" retrieves those without a schema;
null
means that the schema name should not be
used to narrow the searchtable
- a table name; must match the table name as it is stored in
this database
ResultSet
object in which each row is a foreign
key column description
java.sql.SQLException
- if a database access error occursgetImportedKeys(java.lang.String, java.lang.String, java.lang.String)
,
supportsMixedCaseQuotedIdentifiers()
,
storesUpperCaseIdentifiers()
public java.sql.ResultSet getCrossReference(java.lang.String primaryCatalog, java.lang.String primarySchema, java.lang.String primaryTable, java.lang.String foreignCatalog, java.lang.String foreignSchema, java.lang.String foreignTable) throws java.sql.SQLException
Each foreign key column description has the following columns:
null
)
null
)
null
) being exported (may be null
)
null
) being exported (may be null
)
NULL
if
its primary key has been updated
NULL
if
its primary key has been deleted
null
)
null
)
HSQLDB treats unquoted identifiers as case insensitive in SQL but stores them in upper case; it treats quoted identifiers as case sensitive and stores them verbatim. All jdbcDatabaseMetaData methods perform case-sensitive comparison between name (pattern) arguments and the corresponding identifier values as they are stored in the database. Therefore, care must be taken to specify name arguments precisely (including case) as they are stored in the database.
Since 1.7.2, there is an option to support this feature to greater or
lesser degrees. See the documentation specific to the selected system
table provider implementation. The default implementation is
DatabaseInformationFull
.
getCrossReference
in interface java.sql.DatabaseMetaData
primaryCatalog
- a catalog name; must match the catalog name as it is stored in
the database; "" retrieves those without a catalog;
null
means drop catalog name from the selection
criteriaprimarySchema
- a schema name; must match the schema name as it is stored in
the database; "" retrieves those without a schema;
null
means drop schema name from the selection
criteriaprimaryTable
- the name of the table that exports the key; must match the
table name as it is stored in the databaseforeignCatalog
- a catalog name; must match the catalog name as it is stored in
the database; "" retrieves those without a catalog;
null
means drop catalog name from the selection
criteriaforeignSchema
- a schema name; must match the schema name as it is stored in
the database; "" retrieves those without a schema;
null
means drop schema name from the selection
criteriaforeignTable
- the name of the table that imports the key; must match the
table name as it is stored in the database
ResultSet
- each row is a foreign key column
description
java.sql.SQLException
- if a database access error occursgetImportedKeys(java.lang.String, java.lang.String, java.lang.String)
,
supportsMixedCaseQuotedIdentifiers()
,
storesUpperCaseIdentifiers()
public java.sql.ResultSet getTypeInfo() throws java.sql.SQLException
Each type description has the following columns:
null
)
null
)
null
)
null
)
Including 1.7.1, HSQLDB produces a usable but partially incomplete result.
Since 1.7.2, there is an option to support this feature to greater or
lesser degrees. See the documentation specific to the selected system
table provider implementation. The default implementation is
DatabaseInformationFull
.
getTypeInfo
in interface java.sql.DatabaseMetaData
ResultSet
object in which each row is an SQL
type description
java.sql.SQLException
- if a database access error occurspublic java.sql.ResultSet getIndexInfo(java.lang.String catalog, java.lang.String schema, java.lang.String table, boolean unique, boolean approximate) throws java.sql.SQLException
Each index column description has the following columns:
null
)
null
)
null
); null
when TYPE is
tableIndexStatistic
null
when
TYPE is tableIndexStatistic
null
when
TYPE is tableIndexStatistic
null
if sort sequence
is not supported; null
when TYPE is tableIndexStatistic
null
)
HSQLDB treats unquoted identifiers as case insensitive in SQL but stores them in upper case; it treats quoted identifiers as case sensitive and stores them verbatim. All jdbcDatabaseMetaData methods perform case-sensitive comparison between name (pattern) arguments and the corresponding identifier values as they are stored in the database. Therefore, care must be taken to specify name arguments precisely (including case) as they are stored in the database.
Including 1.7.1, HSQLDB produces a usable but partially inclomplete result. Cardinality is never listed, and the approximate parameter is always ignored. No statistics rows are generated.
Since 1.7.2, there is an option to support this feature to greater or
lesser degrees. See the documentation specific to the selected system
table provider implementation. The default implementation is
DatabaseInformationFull
.
getIndexInfo
in interface java.sql.DatabaseMetaData
catalog
- a catalog name; must match the catalog name as it is stored in
this database; "" retrieves those without a catalog;
null
means that the catalog name should not be
used to narrow the searchschema
- a schema name; must match the schema name as it is stored in
this database; "" retrieves those without a schema;
null
means that the schema name should not be
used to narrow the searchtable
- a table name; must match the table name as it is stored in
this databaseunique
- when true, return only indices for unique values; when false,
return indices regardless of whether unique or notapproximate
- when true, result is allowed to reflect approximate or out of
data values; when false, results are requested to be accurate
ResultSet
- each row is an index column
description
java.sql.SQLException
- if a database access error occurssupportsMixedCaseQuotedIdentifiers()
,
storesUpperCaseIdentifiers()
public boolean supportsResultSetType(int type) throws java.sql.SQLException
Starting with 1.8.0, HSQLDB supports TYPE_SCROLL_SENSITIVE.
TODO: Finalize this specification.
supportsResultSetType
in interface java.sql.DatabaseMetaData
type
- defined in java.sql.ResultSet
true
if so; false
otherwise
java.sql.SQLException
- if a database access error occursjdbcConnection
public boolean supportsResultSetConcurrency(int type, int concurrency) throws java.sql.SQLException
Starting with 1.8.0, HSQLDB supports CONCUR_UPDATABLE.
TODO: Finalize this specification.
supportsResultSetConcurrency
in interface java.sql.DatabaseMetaData
type
- defined in java.sql.ResultSet
concurrency
- type defined in java.sql.ResultSet
true
if so; false
otherwise
java.sql.SQLException
- if a database access error occursjdbcConnection
public boolean ownUpdatesAreVisible(int type) throws java.sql.SQLException
ResultSet
object,
the result set's own updates are visible.
Up to and including 1.7.2, HSQLDB does not support updateable result
sets; this method always returns false
.
Starting with 1.8.0, HSQLDB supports updateable result sets.
TODO: Finalize this specification.
Prologue:
The ResultSet rowUpdated() method can be called to determine whether a row has been effected by a visible update since the result set was opened. The ability of a result set to detect changes is orthogonal to its ability to make changes visible. In other words, visible changes are not automatically detected (and changes are not automatically visible). Initial spec:
On the question of detection (and visibility) of (a ResultSet object's) own updates, it is felt that successful row update through the updateable ResultSet api should cause the updates to become immedidately visible in the result set (hence immediately allowing the client to resume accurately detecting others updates if desired). However, there still exist technical issues, such as whether triggered actions at the engine further modifying sumitted update values should or can always be reliably made visible to the client. At some point, it is intended to discuss the various trade-offs in this respect and consider making either alternative available. Unfortunately, JDBC provides no standard API for allowing clients to choose this behaviour under drivers that can support multiple options
In light of the previous discussion, we currently simply return true for all supported result set types.
ownUpdatesAreVisible
in interface java.sql.DatabaseMetaData
type
- the ResultSet
type; one of
ResultSet.TYPE_FORWARD_ONLY
,
ResultSet.TYPE_SCROLL_INSENSITIVE
, or
ResultSet.TYPE_SCROLL_SENSITIVE
true
if updates are visible for the given result
set type; false
otherwise
java.sql.SQLException
- if a database access error occurspublic boolean ownDeletesAreVisible(int type) throws java.sql.SQLException
Up to and including 1.7.2, HSQLDB does not support updateable result
sets; this method always returns false
.
Starting with 1.8.0, HSQLDB supports updateable result sets.
TODO: Finalize this specification.
The ResultSet rowDeleted() method can be called to determine whether a row has been effected by a visible delete since the result set was opened. The ability of a result set to detect changes is orthogonal to its ability to make changes visible. In other words, visible changes are not automatically detected (and changes are not automatically visible).
Initial spec:
An own visible delete is the case where a delete by this result set causes the deleted row to become inaccessible through the JDBC API in the main set of rows.
Because detection and visibility are essentially orthagonal, it follows that under various driver implementations, it may be possible that own deleted rows do or do not become inaccessible after performing a deleteRow operation, and it may or may not be the case that, when own inserted rows do not become inaccessible, it is possible to tell which rows those are.
At this point, it is felt that supporting visibility of own deletes is important, while supporting own deleted detection meaningless, since there is no way to access visibly own deleted rows to detect if they have been deleted. Unfortunately, supporting own visible deletes comes with complications, such as mutating semantics under absolute and relative scrolling. At some point, it is intended to discuss the various trade-offs in this respect and consider making either alternative available. Unfortunately, JDBC provides no standard API for allowing clients to choose behaviour under drivers that can support alternatives.
In light of the previous discussion, we currently simply return true for all supported result set types.
ownDeletesAreVisible
in interface java.sql.DatabaseMetaData
type
- the ResultSet
type; one of
ResultSet.TYPE_FORWARD_ONLY
,
ResultSet.TYPE_SCROLL_INSENSITIVE
, or
ResultSet.TYPE_SCROLL_SENSITIVE
true
if deletes are visible for the given result
set type; false
otherwise
java.sql.SQLException
- if a database access error occurspublic boolean ownInsertsAreVisible(int type) throws java.sql.SQLException
Up to and including 1.7.2, HSQLDB does not support updateable result
sets; this method always returns false
.
Starting with 1.8.0, HSQLDB supports updateable result sets.
TODO: Finalize this specification.
The ResultSet rowInserted() method can be called to determine whether a row has been effected by a visible insert since the result set was opened. The ability of a result set to detect changes is orthogonal to its ability to make changes visible. In other words, visible changes are not automatically detected (and changes are not automatically visible).
Initial spec:
An own visible insert is the case where an insert by this result set causes the inserted row to become accessible through the JDBC API in the main set of rows (i.e. even after the result set moves off the insertRow).
Because detection and visibility are essentially orthagonal, it follows that under various driver implementations, it may be possible that new rows do or do not become generally accessible after performing an insertRow operation , and it may or may not be the case that, when own inserted rows do become generally accessible, it is possible to tell which rows those are.
At this point, it is felt that supporting visibility of own inserts is important, while supporting detection is secondary, relatively speaking. Unfortunately, supporting own visible inserts comes with complications, such as mutating semantics under absolute and relative scrolling. Because of this, the initial descision is to place all own inserted rows at the tail of the result set and leave it at that. At some point, however, it is intended to discuss the various trade-offs in this respect and consider making alternatives available. Unfortunately, JDBC provides no standard API for allowing clients to choose behaviour under drivers that can support alteranties. Another outstanding issue in this regard is whether to allow clients to choose policy as to where own inserted rows are placed (for example, at the end, or immediately after the current row).
In light of the previous discussion, we currently simply return true for all supported result set types.
ownInsertsAreVisible
in interface java.sql.DatabaseMetaData
type
- the ResultSet
type; one of
ResultSet.TYPE_FORWARD_ONLY
,
ResultSet.TYPE_SCROLL_INSENSITIVE
, or
ResultSet.TYPE_SCROLL_SENSITIVE
true
if inserts are visible for the given result
set type; false
otherwise
java.sql.SQLException
- if a database access error occurspublic boolean othersUpdatesAreVisible(int type) throws java.sql.SQLException
Up to and including 1.7.2, HSQLDB does not support updateable result
sets; this method always returns false
.
Starting with 1.8.0, HSQLDB supports updateable result sets.
TODO: Finalize this specification.
othersUpdatesAreVisible
in interface java.sql.DatabaseMetaData
type
- the ResultSet
type; one of
ResultSet.TYPE_FORWARD_ONLY
,
ResultSet.TYPE_SCROLL_INSENSITIVE
, or
ResultSet.TYPE_SCROLL_SENSITIVE
true
if updates made by others are visible for the
given result set type; false
otherwise
java.sql.SQLException
- if a database access error occurspublic boolean othersDeletesAreVisible(int type) throws java.sql.SQLException
Up to and including 1.7.2, HSQLDB does not support updateable result
sets; this method always returns false
.
Starting with 1.8.0, HSQLDB supports updateable result sets.
TODO: Finalize this specification.
Prologue:
The ResultSet rowDeleted() method can be called to determine whether a row has been effected by a visible delete since the result set was opened. The ability of a result set to detect changes is orthogonal to its ability to make changes visible. In other words, visible changes are not automatically detected (and detected changes are not automatically visible).
Initial spec:
An other's detected delete is the case where the ResultSet rowDeleted() method returns true. An other's visible delete is the case where deletion by different result set in the same transaction (or in another session's transcation, if visible via the current transaction isolation level and commited status) causes the deleted row to become inaccessible in this result set.
At this point, it is felt that supporting visibility of other's deletes is of little utility in addition to providing the ability to detect other's deletes. And it comes with complications, such as mutating semantics under absolute and relative scrolling. At some point, however, it is intended to discuss the various trade-offs in this respect and consider making either alternative available. Unfortunately, JDBC provides no standard API for allowing clients to choose behaviour under drivers that can support both.
In light of the previous discussion, we currently simply return false for all supported result set types.
othersDeletesAreVisible
in interface java.sql.DatabaseMetaData
type
- the ResultSet
type; one of
ResultSet.TYPE_FORWARD_ONLY
,
ResultSet.TYPE_SCROLL_INSENSITIVE
, or
ResultSet.TYPE_SCROLL_SENSITIVE
true
if deletes made by others are visible for the
given result set type; false
otherwise
java.sql.SQLException
- if a database access error occurspublic boolean othersInsertsAreVisible(int type) throws java.sql.SQLException
Up to and including 1.7.2, HSQLDB does not support updateable result
sets; this method always returns false
.
Starting with 1.8.0, HSQLDB supports updateable result sets.
TODO: Finalize this specification.
The ResultSet rowInserted() method can be called to determine whether a row has been effected by a visible insert since the result set was opened. The ability of a result set to detect changes is orthogonal to its ability to make changes visible. In other words, visible changes are not automatically detected (and detected changes are not automatically visible).
Initial spec:
An other's detected insert is the case where the ResultSet rowInserted() method returns true. An other's visible insert is the case where insert by different result set in the same transaction (or in another session's transaction, if visible via the current transaction isolation level and commited status) causes a row inserted after this result set was opened to become accessible through the JDBC API.
Because detection and visibility are essentially orthagonal, it follows that under various driver implementations, it may be possible that new rows magically show up in a JDBC result set from time to time, and it may or may not be the case that it is possible to tell which rows those are.
At this point, it is felt that supporting either visibility or detection of other's inserts is of little utility and it comes with complications, such as mutating semantics under absolute and relative scrolling. At some point, however, it is intended to discuss the various trade-offs in this respect and consider making either alternative available. Unfortunately, JDBC provides no standard API for allowing clients to choose behaviour under drivers that can support both.
In light of the previous discussion, we currently simply return false for all supported result set types.
othersInsertsAreVisible
in interface java.sql.DatabaseMetaData
type
- the ResultSet
type; one of
ResultSet.TYPE_FORWARD_ONLY
,
ResultSet.TYPE_SCROLL_INSENSITIVE
, or
ResultSet.TYPE_SCROLL_SENSITIVE
true
if inserts made by others are visible for the
given result set type; false
otherwise
java.sql.SQLException
- if a database access error occurspublic boolean updatesAreDetected(int type) throws java.sql.SQLException
ResultSet.rowUpdated
.
Up to and including 1.7.2, HSQLDB does not support updateable result
sets; this method always returns false
.
Starting with 1.8.0, HSQLDB supports updateable result sets.
TODO: Finalize this specification.
Prologue:
The ResultSet rowUpdated() method can be called to determine whether a row has been effected by a visible update since the result set was opened. The ability of a result set to detect changes is orthogonal to its ability to make changes visible. In other words, visible changes are not automatically detected (and detected changes are not automatically visible). Initial spec:
HSQLDB currently fetches all rows from the database in the execute cycle, essentially making a private copy of the data for the JDBC client. As a result, other's row updates, regardless of transaction isolation, never, at the engine-level, automatically become visible in a result set at some point after it is opened.
But there is no technical limitation upon providing detection of others updates for any result set type, as long as the underlying result set is, at minimum, the primary key columns of a base table, and optionally some collection of base column sites from the same, single table.
It is felt that additional capabilites (detection under multi-table selects, etc), should be left to the engine and protocol implementation at any specific point in development, so we will elect never to specify such things here.
On the question of detection (and visibility) of (a ResultSet object's) own updates, it is felt that successful row update through the updateable ResultSet api should cause the updates to become immedidately visible in the result set (hence immediately allowing the client to resume detecting others updates if desired). However, there still exist technical issues, such as whether triggered actions at the engine further modifying sumitted update values should or can always be reliably made visible to the client. At some point, it is intended to discuss the various trade-offs in this respect and consider making either alternative available. Unfortunately, JDBC provides no standard API for allowing clients to choose this behaviour under drivers that can support multiple options
In light of the previous discussion, we currently simply return true for all supported result set types.
updatesAreDetected
in interface java.sql.DatabaseMetaData
type
- the ResultSet
type; one of
ResultSet.TYPE_FORWARD_ONLY
,
ResultSet.TYPE_SCROLL_INSENSITIVE
, or
ResultSet.TYPE_SCROLL_SENSITIVE
true
if changes are detected by the result set
type; false
otherwise
java.sql.SQLException
- if a database access error occurspublic boolean deletesAreDetected(int type) throws java.sql.SQLException
ResultSet.rowDeleted
. If the method
deletesAreDetected
returns false
, it means
that deleted rows are removed from the result set.
Including 1.7.2, HSQLDB does not support updateable result sets; this
method always returns false
.
Starting with 1.8.0, HSQLDB supports updateable result sets.
TODO: Finalize this specification.
Prologue:
The ResultSet rowDeleted() method can be called to determine whether a row has been effected by a visible delete since the result set was opened. The ability of a result set to detect changes is orthogonal to its ability to make changes visible. In other words, visible changes are not automatically detected (and detected changes are not automatically visible).
Initial spec:
HSQLDB currently fetches all rows from the database in the execute cycle, essentially making a private copy of the data for the JDBC client. As a result, other's row deletions, regardless of transaction isolation, never become visible as "holes" in a result set at some point after it is opened.
But there is no technical limitation upon providing detection of others deletes for any result set type, as long as the underlying result set is, at minimum, the primary key columns of a base table, and optionally some collection of base column sites from the same, single table.
At present, it is felt support for making other's (ResultSet objects in the same transaction and/or isolated session's commited transaction's) deletes visible (for example, as a "hole" in the local result set) is of little utility in addition to providing detection.
It is also felt that additional capabilites (detection under multi-table selects, etc), should be left to the engine and protocol implementation at any specific point in development, so we will elect never to specify such things here.
On the question of detection (and visibility) of (a ResultSet object's) own deletes, it is felt that successful row deletion through the updateable ResultSet api should cause the row to cease being visible in the result set (and hence no longer accessible for invocation of rowDeleted). At some point, it is intended to discuss the various trade-offs in this respect and consider making either alternative available. Unfortunately, JDBC provides no standard API for allowing clients to choose behaviour under drivers that can support both.
In light of the previous discussion, we currently simply return true for all supported result set types.
deletesAreDetected
in interface java.sql.DatabaseMetaData
type
- the ResultSet
type; one of
ResultSet.TYPE_FORWARD_ONLY
,
ResultSet.TYPE_SCROLL_INSENSITIVE
, or
ResultSet.TYPE_SCROLL_SENSITIVE
true
if deletes are detected by the given result
set type; false
otherwise
java.sql.SQLException
- if a database access error occurspublic boolean insertsAreDetected(int type) throws java.sql.SQLException
ResultSet.rowInserted
.
Up to and including 1.7.2, HSQLDB does not support updateable result
sets; this method always returns false
.
Starting with 1.8.0, HSQLDB supports updateable result sets.
TODO: Finalize this specification.
Prologue:
The ResultSet rowInserted() method can be called to determine whether a row has been effected by a visible insert since the result set was opened (for example, under TRANSACTION_READ_COMMITED or better, even while performing a FORWARD_ONLY incremental fetch from the database, rows may be inserted and commited that are elligible for and thus become included in the result set). The ability of a result set to detect changes is orthogonal to its ability to make changes visible. In other words, visible changes are not automatically detected (and detected changes are not automatically visible). Initial spec:
HSQLDB currently fetches all rows from the database in the execute cycle, essentially making a private copy of the data for the JDBC client. As a result, newly inserted rows, regardless of transaction isolation, never become included in a result set at some point after it is opened.
Therefore, we currently always return false here.
insertsAreDetected
in interface java.sql.DatabaseMetaData
type
- the ResultSet
type; one of
ResultSet.TYPE_FORWARD_ONLY
,
ResultSet.TYPE_SCROLL_INSENSITIVE
, or
ResultSet.TYPE_SCROLL_SENSITIVE
true
if changes are detected by the specified
result set type; false
otherwise
java.sql.SQLException
- if a database access error occurspublic boolean supportsBatchUpdates() throws java.sql.SQLException
Starting with 1.7.2, HSQLDB supports batch updates; this method always
returns true
.
supportsBatchUpdates
in interface java.sql.DatabaseMetaData
true
if this database supports batch upcates;
false
otherwise
java.sql.SQLException
- if a database access error occurspublic java.sql.ResultSet getUDTs(java.lang.String catalog, java.lang.String schemaPattern, java.lang.String typeNamePattern, int[] types) throws java.sql.SQLException
JAVA_OBJECT
, STRUCT
, or
DISTINCT
.
Only types matching the catalog, schema, type name and type criteria are returned. They are ordered by DATA_TYPE, TYPE_SCHEM and TYPE_NAME. The type name parameter may be a fully-qualified name. In this case, the catalog and schemaPattern parameters are ignored.
Each type description has the following columns:
null
)
null
)
null
if DATA_TYPE is not DISTINCT or not
STRUCT with REFERENCE_GENERATION = USER_DEFINED)
Note: If the driver does not support UDTs, an empty result set is returned.
HSQLDB treats unquoted identifiers as case insensitive in SQL but stores them in upper case; it treats quoted identifiers as case sensitive and stores them verbatim. All jdbcDatabaseMetaData methods perform case-sensitive comparison between name (pattern) arguments and the corresponding identifier values as they are stored in the database. Therefore, care must be taken to specify name arguments precisely (including case) as they are stored in the database.
Up to and including 1.7.1, HSQLDB does not support UDTs and thus produces an empty result.
Starting with 1.7.2, there is an option to support this feature to greater or lesser degrees. See the documentation specific to the selected system table provider implementation. The default implementation is org.hsqldb.DatabaseInformationFull.
getUDTs
in interface java.sql.DatabaseMetaData
catalog
- a catalog name; must match the catalog name as it is stored in
the database; "" retrieves those without a catalog;
null
means that the catalog name should not be
used to narrow the searchschemaPattern
- a schema pattern name; must match the schema name as it is
stored in the database; "" retrieves those without a schema;
null
means that the schema name should not be
used to narrow the searchtypeNamePattern
- a type name pattern; must match the type name as it is stored
in the database; may be a fully qualified nametypes
- a list of user-defined types (JAVA_OBJECT, STRUCT, or
DISTINCT) to include; null
returns all types
ResultSet
object in which each row describes a UDT
java.sql.SQLException
- if a database access error occurspublic java.sql.Connection getConnection() throws java.sql.SQLException
getConnection
in interface java.sql.DatabaseMetaData
java.sql.SQLException
- if a database access error occurspublic boolean supportsSavepoints() throws java.sql.SQLException
Beginning with 1.7.2, this SQL feature is supported through JDBC as well as SQL.
supportsSavepoints
in interface java.sql.DatabaseMetaData
true
if savepoints are supported;
false
otherwise
java.sql.SQLException
- if a database access error occurspublic boolean supportsNamedParameters() throws java.sql.SQLException
Starting with 1.7.2, HSQLDB supports JDBC named parameters to callable statements; this method returns true.
supportsNamedParameters
in interface java.sql.DatabaseMetaData
true
if named parameters are supported;
false
otherwise
java.sql.SQLException
- if a database access error occurspublic boolean supportsMultipleOpenResults() throws java.sql.SQLException
ResultSet
objects returned from a CallableStatement
object
simultaneously.
Up to and including 1.7.2, HSQLDB does not support multiple ResultSet
objects returned from a CallableStatement
object at all;
this method always returns false
.
supportsMultipleOpenResults
in interface java.sql.DatabaseMetaData
true
if a CallableStatement
object
can return multiple ResultSet
objects
simultaneously; false
otherwise
java.sql.SQLException
- if a database access error occurspublic boolean supportsGetGeneratedKeys() throws java.sql.SQLException
Up to and including 1.7.2, HSQLDB does not support retrieving
autogenerated keys through the JDBC interface at all, although it is
possible to retrieve them in a proprietary fashion; this method always
returns false
.
supportsGetGeneratedKeys
in interface java.sql.DatabaseMetaData
true
if auto-generated keys can be retrieved after
a statement has executed; false
otherwise
java.sql.SQLException
- if a database access error occurspublic java.sql.ResultSet getSuperTypes(java.lang.String catalog, java.lang.String schemaPattern, java.lang.String typeNamePattern) throws java.sql.SQLException
Only supertype information for UDTs matching the catalog, schema, and type name is returned. The type name parameter may be a fully-qualified name. When the UDT name supplied is a fully-qualified name, the catalog and schemaPattern parameters are ignored.
If a UDT does not have a direct super type, it is not listed here. A row
of the ResultSet
object returned by this method describes
the designated UDT and a direct supertype. A row has the following
columns:
null
)
null
)
null
)
null
)
Note: If the driver does not support type hierarchies, an empty result set is returned.
HSQLDB treats unquoted identifiers as case insensitive in SQL but stores them in upper case; it treats quoted identifiers as case sensitive and stores them verbatim. All jdbcDatabaseMetaData methods perform case-sensitive comparison between name (pattern) arguments and the corresponding identifier values as they are stored in the database. Therefore, care must be taken to specify name arguments precisely (including case) as they are stored in the database.
Including 1.7.1, this JDBC feature is not supported; calling this method throws a SQLException stating that the operation is not supported.
Since 1.7.2, there is an option to support this feature to greater or
lesser degrees. See the documentation specific to the selected system
table provider implementation. The default implementation is
DatabaseInformationFull
.
getSuperTypes
in interface java.sql.DatabaseMetaData
catalog
- a catalog name; "" retrieves those without a catalog;
null
means drop catalog name from the selection
criteriaschemaPattern
- a schema name pattern; "" retrieves those without a schematypeNamePattern
- a UDT name pattern; may be a fully-qualified name
ResultSet
object in which a row gives
information about the designated UDT
java.sql.SQLException
- if a database access error occurspublic java.sql.ResultSet getSuperTables(java.lang.String catalog, java.lang.String schemaPattern, java.lang.String tableNamePattern) throws java.sql.SQLException
Only supertable information for tables matching the catalog, schema and table name are returned. The table name parameter may be a fully- qualified name, in which case, the catalog and schemaPattern parameters are ignored. If a table does not have a super table, it is not listed here. Supertables have to be defined in the same catalog and schema as the sub tables. Therefore, the type description does not need to include this information for the supertable.
Each type description has the following columns:
null
)
null
)
Note: If the driver does not support type hierarchies, an empty result set is returned.
HSQLDB treats unquoted identifiers as case insensitive in SQL but stores them in upper case; it treats quoted identifiers as case sensitive and stores them verbatim. All jdbcDatabaseMetaData methods perform case-sensitive comparison between name (pattern) arguments and the corresponding identifier values as they are stored in the database. Therefore, care must be taken to specify name arguments precisely (including case) as they are stored in the database.
Including 1.7.1, this JDBC feature is not supported; calling this method throws a SQLException stating that the operation is not supported.
Since 1.7.2, there is an option to support this feature to greater or
lesser degrees. See the documentation specific to the selected system
table provider implementation. The default implementation is
DatabaseInformationFull
.
getSuperTables
in interface java.sql.DatabaseMetaData
catalog
- a catalog name; "" retrieves those without a catalog;
null
means drop catalog name from the selection
criteriaschemaPattern
- a schema name pattern; "" retrieves those without a schematableNamePattern
- a table name pattern; may be a fully-qualified name
ResultSet
object in which each row is a type
description
java.sql.SQLException
- if a database access error occurspublic java.sql.ResultSet getAttributes(java.lang.String catalog, java.lang.String schemaPattern, java.lang.String typeNamePattern, java.lang.String attributeNamePattern) throws java.sql.SQLException
Descriptions are returned only for attributes of UDTs matching the catalog, schema, type, and attribute name criteria. They are ordered by TYPE_SCHEM, TYPE_NAME and ORDINAL_POSITION. This description does not contain inherited attributes.
The ResultSet
object that is returned has the following
columns:
null
)
null
)
null
)
null
)
null
if DATA_TYPE isn't REF)
null
if DATA_TYPE isn't REF)
null
if the DATA_TYPE isn't REF)
null
if DATA_TYPE isn't DISTINCT or user-generated REF)
HSQLDB treats unquoted identifiers as case insensitive in SQL but stores them in upper case; it treats quoted identifiers as case sensitive and stores them verbatim. All jdbcDatabaseMetaData methods perform case-sensitive comparison between name (pattern) arguments and the corresponding identifier values as they are stored in the database. Therefore, care must be taken to specify name arguments precisely (including case) as they are stored in the database.
Including 1.7.1, this JDBC feature is not supported; calling this method throws a SQLException stating that the operation is not supported.
Since 1.7.2, there is an option to support this feature to greater or
lesser degrees. See the documentation specific to the selected system
table provider implementation. The default implementation is
DatabaseInformationFull
.
getAttributes
in interface java.sql.DatabaseMetaData
catalog
- a catalog name; must match the catalog name as it is stored in
the database; "" retrieves those without a catalog;
null
means that the catalog name should not be
used to narrow the searchschemaPattern
- a schema name pattern; must match the schema name as it is
stored in the database; "" retrieves those without a schema;
null
means that the schema name should not be
used to narrow the searchtypeNamePattern
- a type name pattern; must match the type name as it is stored
in the databaseattributeNamePattern
- an attribute name pattern; must match the attribute name as it
is declared in the database
ResultSet
object in which each row is an
attribute description
java.sql.SQLException
- if a database access error occurspublic boolean supportsResultSetHoldability(int holdability) throws java.sql.SQLException
Starting with 1.7.2, HSQLDB returns true for HOLD_CURSORS_OVER_COMMIT, else false.
supportsResultSetHoldability
in interface java.sql.DatabaseMetaData
holdability
- one of the following constants:
ResultSet.HOLD_CURSORS_OVER_COMMIT
or
ResultSet.CLOSE_CURSORS_AT_COMMIT
true
if so; false
otherwise
java.sql.SQLException
- if a database access error occursjdbcConnection
public int getResultSetHoldability() throws java.sql.SQLException
ResultSet
object.
Starting with HSQLDB 1.7.2, this JDBC feature is supported.
Calling this method returns HOLD_CURSORS_OVER_COMMIT, since HSQLDB ResultSet objects are never closed as the result of an implicit or explicit commit operation.
getResultSetHoldability
in interface java.sql.DatabaseMetaData
ResultSet.HOLD_CURSORS_OVER_COMMIT
or
ResultSet.CLOSE_CURSORS_AT_COMMIT
java.sql.SQLException
- if a database access error occurspublic int getDatabaseMajorVersion() throws java.sql.SQLException
Up to and including 1.7.1, this JDBC feature is not supported; calling this method throws a SQLException stating that the function is not supported.
Starting with 1.7.2, the feature is supported under JDK14 builds.
This value is retrieved through an SQL call to the new
Library.getDatabaseMajorVersion
method which allows correct
determination of the database major version for both local and remote
database instances.
getDatabaseMajorVersion
in interface java.sql.DatabaseMetaData
java.sql.SQLException
- if a database access error occurspublic int getDatabaseMinorVersion() throws java.sql.SQLException
Up to and including 1.7.1, this JDBC feature is not supported; calling this method throws a SQLException stating that the function is not supported.
Starting with 1.7.2, the feature is supported under JDK14 builds.
This value is retrieved through an SQL call to the new
Library.getDatabaseMinorVersion
method which allows correct
determination of the database minor version for both local and remote
database instances.
getDatabaseMinorVersion
in interface java.sql.DatabaseMetaData
java.sql.SQLException
- if a database access error occurspublic int getJDBCMajorVersion() throws java.sql.SQLException
Up to and including 1.7.1, this JDBC feature is not supported; calling this method throws a SQLException stating that the function is not supported.
Starting with 1.7.2, the feature is supported under JDK14 builds.
getJDBCMajorVersion
in interface java.sql.DatabaseMetaData
java.sql.SQLException
- if a database access error occurspublic int getJDBCMinorVersion() throws java.sql.SQLException
Up to and including 1.7.1, this JDBC feature is not supported; calling this method throws a SQLException stating that the function is not supported.
Starting with 1.7.2, the feature is supported under JDK14 builds.
getJDBCMinorVersion
in interface java.sql.DatabaseMetaData
java.sql.SQLException
- if a database access error occurspublic int getSQLStateType() throws java.sql.SQLException
SQLException.getSQLState
is X/Open (now known as Open
Group) SQL CLI or SQL99.
Up to HSQLDB 1.7.1, this JDBC feature is not supported.
Starting with 1.7.2, HSQLDB returns sqlStateSQL99
.
getSQLStateType
in interface java.sql.DatabaseMetaData
java.sql.SQLException
- if a database access error occurspublic boolean locatorsUpdateCopy() throws java.sql.SQLException
Up to and including 1.7.2, HSQLDB updates the LOB directly. This method return false.
locatorsUpdateCopy
in interface java.sql.DatabaseMetaData
true
if updates are made to a copy of the LOB;
false
if updates are made directly to the LOB
java.sql.SQLException
- if a database access error occurspublic boolean supportsStatementPooling() throws java.sql.SQLException
Up to and including 1.7.2, HSQLDB does not support statement pooling. This method returns false. Starting with 1.8.0, HSQLDB may support statement pooling. TODO: Finalize this specification.
supportsStatementPooling
in interface java.sql.DatabaseMetaData
true
is so; false
otherwise
java.sql.SQLException
- if a database access error occurs
|
||||||||||
PREV CLASS NEXT CLASS | FRAMES NO FRAMES | |||||||||
SUMMARY: NESTED | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD |