Overview | Package | Class | Tree | Deprecated | Index | Help

3.00.12
PREV CLASS NEXT CLASS | FRAMES NO FRAMES
SUMMARY: INNER | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD

## interbase.interclient
Class Connection

    java.lang.Object
      |
      +--interbase.interclient.Connection

All Implemented Interfaces:
  Connection

public final class Connection
extends Object
implements Connection

Represents a database session and provides a factory for SQL statements.

Within the context of a Connection, SQL statements are executed and results are returned.

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

Note: By default the Connection automatically commits changes after executing each statement. If auto commit has been disabled, an explicit commit must be done or database changes will not be saved.

InterClient note: One of InterBase's biggest strengths is the row-level locking provided by our versioning engine. This versioning of records is of great importance for applications in which there is a lot of updating going on, and a high level of concurrency is desired. The default InterBase snapshot transaction mode allows for writers not to block readers, and readers not to block writers. Other DBMSs will serialize a lot of operations that InterBase would allow to operate concurrently.

Since:
  JDBC 1, with extended behavior in JDBC 2

Field Summary
`static int` | `IGNORE_UNCOMMITTED_RECORD_VERSIONS_ON_READ` A read-committed version-acknowledgement mode in which transactions read the most recent committed updates of concurrent transactions.
`static int` | `LOCK_RESOLUTION_NO_WAIT` The InterBase lock resolution protocol in which a transaction will not wait for locks to be released, but instead, a LockConflictException is thrown immediately.
`static int` | `LOCK_RESOLUTION_WAIT` The default lock resolution mode for InterBase in which a transaction will wait for a database lock.
`static int` | `RECOGNIZE_UNCOMMITTED_RECORD_VERSIONS_ON_READ` A read-committed version-acknowledgement mode in which transactions read the last committed update but not if an uncommitted update is pending.
`static int` | `TABLELOCK_PROTECTED_READ` A table lock in which this transaction reserves exclusive access to a table for reads.
`static int` | `TABLELOCK_PROTECTED_WRITE` A table lock in which this transaction reserves exclusive access to a table for writes.
`static int` | `TABLELOCK_SHARED_READ` A table lock in which a table may be accessed read-only, and may also be shared by concurrent transactions.
`static int` | `TABLELOCK_SHARED_WRITE` The default table lock for snapshot and read-committed transactions in which a table may be shared by concurrent transactions for writes.
`static int` | `TRANSACTION_NONE` JDBC Isolation level in which transactions are not supported.
`static int` | `TRANSACTION_READ_COMMITTED` JDBC Isolation level in which dirty reads are prevented; non-repeatable reads and phantom reads can occur.
`static int` | `TRANSACTION_READ_UNCOMMITTED` JDBC Isolation level in which dirty reads, non-repeatable reads and phantom reads can occur.
`static int` | `TRANSACTION_REPEATABLE_READ` JDBC Isolation level in which dirty reads and non-repeatable reads are prevented; phantom reads can occur.
`static int` | `TRANSACTION_SERIALIZABLE` JDBC Isolation level in which dirty reads, non-repeatable reads and phantom reads are prevented.
`static int` | `TRANSACTION_SNAPSHOT` A synonym for `TRANSACTION_SERIALIZABLE`.
`static int` | `TRANSACTION_SNAPSHOT_TABLE_STABILITY` A native InterBase isolation which ensures exclusive write-access to tables which are being modified.

Method Summary
`void` | `clearWarnings()` After this call, getWarnings returns null until a new warning is reported for this Connection.
`void` | `close()` In some cases, it is desirable to immediately release a Connection's database and JDBC resources instead of waiting for them to be automatically released; the close method provides this immediate release.
`void` | `commit()` Commit makes all changes made since the previous commit/rollback permanent and releases any database locks currently held by the Connection.
`void` | `commitRetain()` Like commit but keeps your snapshot and retains your transaction context.
`Statement` | `createStatement()` Create a Statement as a container for executing SQL on this connection.
`Statement` | `createStatement(int resultSetType, int resultSetConcurrency)` Same as `createStatement()` above, but allows the default result set type and result set concurrency type to be overridden.
`protected void` | `finalize()` A connection will be closed when its finalizer is called by the garbage collector.
`int` | `getAttachmentSQLDialect()` Gets this Connection's current SQL dialect.
`boolean` | `getAutoCommit()` Get the current auto-commit state.
`String` | `getCatalog()` Return the Connection's current catalog name.
`int` | `getLockResolution()` Gets this Connection's current lock resolution mode.
`DatabaseMetaData` | `getMetaData()` A Connection's database is able to provide information describing its tables, its supported SQL grammar, its stored procedures, the capabilities of this connection, etc.
`int` | `getTableLock(String table)` Gets the current table lock mode on a table for this transaction.
`int` | `getTransactionId()` Get the InterBase transaction id for the current transaction.
`int` | `getTransactionIsolation()` Get this Connection's current transaction isolation mode.
`Map` | `getTypeMap()` Get the type-map object associated with this connection.
`int` | `getVersionAcknowledgement()` Gets the current version-acknowledgement mode for a read-committed transaction.
`SQLWarning` | `getWarnings()` The first warning reported by calls on this Connection is returned.
`boolean` | `inTransaction()` Is a transaction currently active on this connection.
`boolean` | `isClosed()` Tests to see if a Connection is closed.
`boolean` | `isReadOnly()` Tests to see if the connection is in read-only mode.
`String` | `nativeSQL(String sql)` Gets the native SQL recognized by the underlying DBMS for the given JDBC sql string.
`CallableStatement` | `prepareCall(String sql)` Prepare a CallableStatement for subsequent use on this connection.
`CallableStatement` | `prepareCall(String sql, int resultSetType, int resultSetConcurrency)` Same as the JDBC 1 `prepareCall(sql)`, but allows the default result set type and result set concurrency type to be overridden.
`PreparedStatement` | `prepareStatement(String sql)` Prepare SQL as a `PreparedStatement` for subsequent use on this connection.
`PreparedStatement` | `prepareStatement(String sql, int resultSetType, int resultSetConcurrency)` Same as `prepareStatement()` above, but allows the default result set type and result set concurrency type to be overridden.
`void` | `rollback()` Rollback drops all changes made since the previous commit/rollback and releases any database locks currently held by the Connection.
`void` | `setAutoCommit(boolean enableAutoCommit)` Enable or disable auto-commit on this connection.
`void` | `setCatalog(String catalog)` A sub-space of this Connection's database may be selected by setting a catalog name.
`void` | `setLockResolution(int mode)` Configures the transaction lock resolution protocol.
`void` | `setReadOnly(boolean readOnly)` You can put a connection in read-only mode as a hint to enable database optimizations.
`void` | `setTableLock(String table, int tableLock)` Specify an InterBase lock on a table.
`void` | `setTransactionIsolation(int level)` You can call this method to try to change the transaction isolation level using one of the TRANSACTION_* values.
`void` | `setTypeMap(Map map)` Install a type-map object as the default type-map for this connection.
`void` | `setVersionAcknowledgement(int mode)` Configures a read-committed transaction to either recognize or ignore uncommitted record versions of a concurrent transaction on read.

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

Field Detail

### TRANSACTION_NONE

    public static final int TRANSACTION_NONE

  JDBC Isolation level in which transactions are not supported.
  Since:
    JDBC 1

### TRANSACTION_READ_UNCOMMITTED

    public static final int TRANSACTION_READ_UNCOMMITTED

  JDBC Isolation level in which dirty reads, non-repeatable reads and phantom reads can occur. This level allows a row changed by one transaction to be read by another transaction before any changes in that row have been committed (a "dirty read"). If any of the changes are rolled back, the second transaction will have retrieved an invalid row.

  InterClient note: InterBase does not support such an unrestricted and dangerous isolation level.

  Since:
    JDBC 1

### TRANSACTION_READ_COMMITTED

    public static final int TRANSACTION_READ_COMMITTED

  JDBC Isolation level in which dirty reads are prevented; non-repeatable reads and phantom reads can occur. This level only prohibits a transaction from reading a row with uncommitted changes in it.

  InterClient notes: InterBase supports two kinds of read-committed transactions. The first kind of read-committed transaction, known as read-committed record-versions, can read a committed record even while it's being modified by another transaction, that is the record may have an uncommitted version. The second kind of read-committed transaction, known as read-committed no-record-versions, will either block or abort while trying to read a record version which has an uncommitted version (depending on the lock resolution mode of wait or no-wait). The two modes may be configured using `setVersionAcknowledgement(int mode)` with either mode `IGNORE_UNCOMMITTED_RECORD_VERSIONS_ON_READ` or `RECOGNIZE_UNCOMMITTED_RECORD_VERSIONS_ON_READ`. The default mode for a read-committed transaction is `RECOGNIZE_UNCOMMITTED_RECORD_VERSIONS_ON_READ`.

  Since:
    JDBC 1

### TRANSACTION_REPEATABLE_READ

    public static final int TRANSACTION_REPEATABLE_READ

  JDBC Isolation level in which dirty reads and non-repeatable reads are prevented; phantom reads can occur. This level prohibits a transaction from reading a row with uncommitted changes in it, and it also prohibits the situation where one transaction reads a row, a second transaction alters the row, and the first transaction rereads the row, getting different values the second time (a "non-repeatable read").

  InterClient note: Repeatable reads are achieved using InterBase's snapshot model of concurrency, which was known as Concurrency mode prior to v4.

  Since:
    JDBC 1

### TRANSACTION_SERIALIZABLE

    public static final int TRANSACTION_SERIALIZABLE

  JDBC Isolation level in which dirty reads, non-repeatable reads and phantom reads are prevented. This level includes the prohibitions in TRANSACTION_REPEATABLE_READ and further prohibits the situation where one transaction reads all rows that satisfy a WHERE condition, a second transaction inserts a row that satisfies that WHERE condition, and the first transaction rereads for the same condition, retrieving the additional "phantom" row in the second read.

  InterClient note: InterBase's multi-generational architecture, aka versioning engine, provides the superb implementation of serializability through the snapshot model of concurrency. Under the snapshot model, once a transaction starts, a snapshot of committed records is taken when the transaction starts, the snapshot is insensitive to the record changes of other transactions. Only changes made within the local transaction itself are visible to the localized snapshot. Writers in another transaction will not block readers within the local transaction because the local transaction reads from the local snapshot only. Similarly Readers in another transaction will not block writes within the local transaction. However, serializability and effective record locking is achieved because a write within the local transaction will block or abort (depending on the lock resolution mode of wait or no-wait) if another transaction has an uncommitted modification (or version) of that record. In other words, an uncommitted record version provides an effective write-lock on a record.

  This native isolation was known as Concurrency mode prior to v4, and is also described as the Snapshot model of concurrency.

  Since:
    JDBC 1

### TRANSACTION_SNAPSHOT

    public static final int TRANSACTION_SNAPSHOT

  A synonym for `TRANSACTION_SERIALIZABLE`.

  This is the native default isolation mode for InterBase, and was formerly known as Concurrency mode prior to v4.

  SNAPSHOT transactions keep a snapshot of the database when the transaction starts and do not see the committed updates of simultaneous transactions. This versioning of records provides for serializability in which writers don't block readers, and readers don't block writers. Thereby allowing for high transaction throughput. This isolation level is possible because of InterBase's multi-generational architecture. Although rare, update side effects can occur with this isolation level, but these can be avoided through the use of triggers or validity constraints.

  This variable is identical to the JDBC isolation level `TRANSACTION_SERIALIZABLE` and exists only for the sake of promoting InterBase terminology.

  See Also:
    `setTransactionIsolation(int)`
  Since:
    Extension, proposed for InterClient 3.0

### TRANSACTION_SNAPSHOT_TABLE_STABILITY

    public static final int TRANSACTION_SNAPSHOT_TABLE_STABILITY

  A native InterBase isolation which ensures exclusive write-access to tables which are being modified. This is the most restrictive InterBase isolation mode in which a transaction is prevented from accessing tables if they are being written by other transactions; it also prevents other transactions from writing to a table once this transaction writes to it. This isolation level is designed to guarantee that if a transaction writes to a table before other simultaneous transactions, then only it can change a table's data.

  This isolation level was formerly known as Consistency mode prior to v4.

  See Also:
    `setTransactionIsolation(int)`
  Since:
    Extension, proposed for InterClient 3.0

### LOCK_RESOLUTION_WAIT

    public static final int LOCK_RESOLUTION_WAIT

  The default lock resolution mode for InterBase in which a transaction will wait for a database lock.

  This is the lock resolution protocol in which a transaction will wait for conflicting transactions to release locks.

  Note: This native InterBase resolution is also known as WAIT mode.

  See Also:
    `setLockResolution(int)`
  Since:
    Extension, proposed for InterClient 3.0

### LOCK_RESOLUTION_NO_WAIT

    public static final int LOCK_RESOLUTION_NO_WAIT

  The InterBase lock resolution protocol in which a transaction will not wait for locks to be released, but instead, a LockConflictException is thrown immediately.

  Note: This native InterBase resolution is also known as NO WAIT mode.

  See Also:
    `setLockResolution(int)`
  Since:
    Extension, proposed for InterClient 3.0

### IGNORE_UNCOMMITTED_RECORD_VERSIONS_ON_READ

    public static final int IGNORE_UNCOMMITTED_RECORD_VERSIONS_ON_READ

  A read-committed version-acknowledgement mode in which transactions read the most recent committed updates of concurrent transactions. Uncommitted record versions of concurrent transactions are ignored on read.

  This is the default behavior for read-committed transactions in InterClient and the BDE. This version-acknowlegement mode is only meaningful for read-committed transactions.

  Note: This native InterBase read-committed mode is also known as RECORD_VERSION.

  See Also:
    `TRANSACTION_READ_COMMITTED`, `setVersionAcknowledgement(int)`
  Since:
    Extension, proposed for InterClient 3.0

### RECOGNIZE_UNCOMMITTED_RECORD_VERSIONS_ON_READ

    public static final int RECOGNIZE_UNCOMMITTED_RECORD_VERSIONS_ON_READ

  A read-committed version-acknowledgement mode in which transactions read the last committed update but not if an uncommitted update is pending.

  If an uncommitted update is pending, then this transaction will either wait on read or throw a `LockConflictException`, depending on the lock resolution mode.

  This version-acknowlegement mode is only meaningful for read-committed transactions.

  Note: This native InterBase read-committed mode is also known as `NO RECORD_VERSION`.

  See Also:
    `TRANSACTION_READ_COMMITTED`, `setVersionAcknowledgement(int)`, `setLockResolution(int)`
  Since:
    Extension, proposed for InterClient 3.0

### TABLELOCK_SHARED_WRITE

    public static final int TABLELOCK_SHARED_WRITE

  The default table lock for snapshot and read-committed transactions in which a table may be shared by concurrent transactions for writes. So concurrent transactions may both write to the same tables.

  Permits table writes by concurrency and read-committed mode transactions with write access; Permits table reads by concurrency and read-committed mode transactions with read access.

  This table lock mode is disallowed for `TRANSACTION_SNAPSHOT_TABLE_STABILITY` transactions, which are inherently protected.

  See Also:
    `setTableLock(String,int)`
  Since:
    Extension, proposed for InterClient 3.0, not yet supported

### TABLELOCK_SHARED_READ

    public static final int TABLELOCK_SHARED_READ

  A table lock in which a table may be accessed read-only, and may also be shared by concurrent transactions. Table writes for this transaction are disallowed.

  Permits table writes by other transactions with write access; Permits table reads by any transaction.

  See Also:
    `setTableLock(String,int)`
  Since:
    Extension, proposed for InterClient 3.0, not yet supported

### TABLELOCK_PROTECTED_WRITE

    public static final int TABLELOCK_PROTECTED_WRITE

  A table lock in which this transaction reserves exclusive access to a table for writes. Other transactions may not write to the locked table.

  Permits exclusive table writes only; Permits table reads by snapshot and read-committed mode transactions with read access.

  See Also:
    `setTableLock(String,int)`
  Since:
    Extension, proposed for InterClient 3.0, not yet supported

### TABLELOCK_PROTECTED_READ

    public static final int TABLELOCK_PROTECTED_READ

  A table lock in which this transaction reserves exclusive access to a table for reads. No other transaction may write to the locked table.

  Disallows all table writes; Permits table reads by all transactions.

  See Also:
    `setTableLock(String,int)`
  Since:
    Extension, proposed for InterClient 3.0, not yet supported

Method Detail

### finalize

    protected void finalize()
                     throws Throwable

  A connection will be closed when its finalizer is called by the garbage collector. There is no guarantee that the garbage collector will ever run, and in general will not run when an application terminates abruptly without closing its connections.

  Therefore, it is recommended that connections be explicitly closed even if your application throws an exception. This can be achieved by placing a call to close() in a finally clause of your application as follows

       try {
         ...
       }
       finally {
         if (connection != null)
           try { connection.close (); } catch (SQLException ohWell) {}
       }

  Or alternatively, use the System.runFinalizersOnExit () method.

  Overrides:
    `finalize` in class `Object`
  Since:
    Extension

### createStatement

    public Statement createStatement()
                              throws SQLException

  Create a Statement as a container for executing SQL on this connection. SQL statements without parameters are normally executed using Statement objects. If the same SQL statement is executed many times, it is more efficient to use a PreparedStatement.

  JDBC 2 note: Result sets created using the returned Statement will have forward-only type, and read-only concurrency, by default.

  Specified by:
    `createStatement` in interface `Connection`
  Returns:
    a new Statement object
  Throws:
    `SQLException` - if a database access error occurs.
  Since:
    JDBC 1

### prepareStatement

    public PreparedStatement prepareStatement(String sql)
                                       throws SQLException

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

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

  JDBC 2 note: Result sets created using the returned PreparedStatement will have forward-only type, and read-only concurrency, by default.

  InterClient note: InterBase supports statement precompilation of prepared statements, allowing for efficient execution of repeated statement executions. Moreover, unlike many other vendors, InterBase allows prepared statements to remain open across transaction commits and rollbacks.

  Specified by:
    `prepareStatement` in interface `Connection`
  Parameters:
    `sql` - a SQL statement that may contain one or more '?' IN parameter placeholders.
  Returns:
    a new PreparedStatement object containing the pre-compiled statement.
  Throws:
    `SQLException` - if a database access error occurs.
  Since:
    JDBC 1

### prepareCall

    public CallableStatement prepareCall(String sql)
                                  throws SQLException

  Prepare a CallableStatement for subsequent use on this connection. A SQL stored procedure call statement is handled by creating a CallableStatement for it. The CallableStatement provides methods for setting up its IN and OUT parameters, and methods for executing it.

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

  JDBC 2 note: Result sets created using the returned CallableStatement will have forward-only type, and read-only concurrency, by default.

  InterClient note: InterBase supports statement precompilation of callable statements, allowing for efficient execution of repeated stored procedure calls. Moreover, unlike many other vendors, InterBase allows callable statements to remain open across transaction commits and rollbacks.

  Specified by:
    `prepareCall` in interface `Connection`
  Parameters:
    `sql` - a SQL statement that may contain one or more '?' parameter placeholders. Typically this statement is a JDBC function call escape string.
  Returns:
    a new CallableStatement object containing the pre-compiled SQL statement.
  Throws:
    `SQLException` - if a database access error occurs.
  Since:
    JDBC 1

### nativeSQL

    public String nativeSQL(String sql)
                     throws SQLException

  Gets the native SQL recognized by the underlying DBMS for the given JDBC sql string. A driver may convert the JDBC sql grammar into its system's native SQL grammar prior to sending it; nativeSQL returns the native form of the statement that the driver would have sent.
  Specified by:
    `nativeSQL` in interface `Connection`
  Parameters:
    `sql` - a SQL statement that may contain one or more '?' parameter placeholders
  Returns:
    the native form of this statement
  Throws:
    `SQLException` - if a database access error occurs.
  Since:
    JDBC 1

### setAutoCommit

    public void setAutoCommit(boolean enableAutoCommit)
                       throws SQLException

  Enable or disable auto-commit on this connection. If a connection is in auto-commit mode, then all its SQL statements will be executed and committed as individual transactions. Otherwise, its SQL statements are grouped into transactions that are terminated by either commit() or rollback(). By default, new connections are in auto-commit mode.

  The commit occurs when the statement completes or the next execute occurs, whichever comes first. In the case of statements returning a ResultSet, the statement completes when the last row of the ResultSet has been retrieved or the ResultSet has been closed. In advanced cases, a single statement may return multiple results as well as output parameter values. Here the commit occurs when all results and output param values have been retrieved.

  InterClient note: Although a sequence of auto-committed statements is in general less efficient than a manually committed sequence, InterClient efficiently auto-commits using a native auto-commit mode.

  Specified by:
    `setAutoCommit` in interface `Connection`
  Parameters:
    `enableAutoCommit` - true enables auto-commit; false disables auto-commit.
  Throws:
    `SQLException` - if a database access error occurs.
  Since:
    JDBC 1

### getAutoCommit

    public boolean getAutoCommit()
                          throws SQLException

  Get the current auto-commit state.
  Specified by:
    `getAutoCommit` in interface `Connection`
  Returns:
    Current state of auto-commit mode.
  Throws:
    `SQLException` - if a database-access error occurs.
  Since:
    JDBC 1
  See Also:
    `setAutoCommit(boolean)`

### commit

    public void commit()
                throws SQLException

  Commit makes all changes made since the previous commit/rollback permanent and releases any database locks currently held by the Connection. This method should only be used when auto commit has been disabled.
  Specified by:
    `commit` in interface `Connection`
  Throws:
    `SQLException` - if a database access error occurs.
  Since:
    JDBC 1
  See Also:
    `setAutoCommit(boolean)`

### rollback

    public void rollback()
                  throws SQLException

  Rollback drops all changes made since the previous commit/rollback and releases any database locks currently held by the Connection. This method should only be used when auto commit has been disabled.
  Specified by:
    `rollback` in interface `Connection`
  Throws:
    `SQLException` - if a database access error occurs.
  Since:
    JDBC 1
  See Also:
    `setAutoCommit(boolean)`

### close

    public void close()
               throws SQLException

  In some cases, it is desirable to immediately release a Connection's database and JDBC resources instead of waiting for them to be automatically released; the close method provides this immediate release.

  Note: A Connection is automatically closed when it is garbage collected. Certain fatal errors also result in a closed Connection.

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

### isClosed

    public boolean isClosed()
                     throws SQLException

  Tests to see if a Connection is closed.
  Specified by:
    `isClosed` in interface `Connection`
  Returns:
    true if the connection is closed; false if it's still open.
  Throws:
    `SQLException` - if a database-access error occurs.
  Since:
    JDBC 1

### getMetaData

    public DatabaseMetaData getMetaData()
                                 throws SQLException

  A Connection's database is able to provide information describing its tables, its supported SQL grammar, its stored procedures, the capabilities of this connection, etc. This information is made available through a DatabaseMetaData object.
  Specified by:
    `getMetaData` in interface `Connection`
  Returns:
    a DatabaseMetaData object for this Connection.
  Throws:
    `SQLException` - if a database access error occurs.
  Since:
    JDBC 1

### setReadOnly

    public void setReadOnly(boolean readOnly)
                     throws SQLException

  You can put a connection in read-only mode as a hint to enable database optimizations.

  Note: setReadOnly cannot be called while in the middle of a transaction.

  InterClient note: A read-only transaction may only read data, and has no write access to tables.

  Specified by:
    `setReadOnly` in interface `Connection`
  Parameters:
    `readOnly` - true enables read-only mode; false disables read-only mode.
  Throws:
    `SQLException` - if a database access error occurs.
  Since:
    JDBC 1

### isReadOnly

    public boolean isReadOnly()
                       throws SQLException

  Tests to see if the connection is in read-only mode.
  Specified by:
    `isReadOnly` in interface `Connection`
  Returns:
    true if connection is read-only
  Throws:
    `SQLException` - if a database access error occurs.
  Since:
    JDBC 1

### setCatalog

    public void setCatalog(String catalog)
                    throws SQLException

  A sub-space of this Connection's database may be selected by setting a catalog name. If the driver does not support catalogs it will silently ignore this request.

  InterClient note: InterBase does not support catalogs so this request is ignored and is effectively a no-op.

  Specified by:
    `setCatalog` in interface `Connection`
  Throws:
    `SQLException` - if a database access error occurs.
  Since:
    JDBC 1

### getCatalog

    public String getCatalog()
                      throws SQLException

  Return the Connection's current catalog name.

  InterClient note: Always returns `null`. InterBase does not support catalogs.

  Specified by:
    `getCatalog` in interface `Connection`
  Returns:
    the current catalog name or null
  Throws:
    `SQLException` - if a database access error occurs.
  Since:
    JDBC 1, not supported

### setTransactionIsolation

    public void setTransactionIsolation(int level)
                                 throws SQLException

  You can call this method to try to change the transaction isolation level using one of the TRANSACTION_* values.

  Note: setTransactionIsolation cannot be called while in the middle of a transaction.

  InterClient note: InterBase supports the JDBC isolation levels `TRANSACTION_REPEATABLE_READ`, `TRANSACTION_READ_COMMITTED`, `TRANSACTION_SERIALIZABLE` as well as an additional native isolation level `TRANSACTION_SNAPSHOT_TABLE_STABILITY` surfaced as extension to the base JDBC API. The default isolation level is `TRANSACTION_SERIALIZABLE`.

  Specified by:
    `setTransactionIsolation` in interface `Connection`
  Parameters:
    `level` - one of the TRANSACTION_* isolation values with the exception of TRANSACTION_NONE; some databases may not support other values.
  Throws:
    `SQLException` - if a database access error occurs.
  Since:
    JDBC 1
  See Also:
    `DatabaseMetaData.supportsTransactionIsolationLevel(int)`, `setLockResolution(int)`, `setTableLock(java.lang.String,int)`

### getTransactionIsolation

    public int getTransactionIsolation()
                                throws SQLException

  Get this Connection's current transaction isolation mode.
  Specified by:
    `getTransactionIsolation` in interface `Connection`
  Returns:
    the current transaction mode TRANSACTION_* value.
  Throws:
    `SQLException` - if a database access error occurs.
  Since:
    JDBC 1

### getWarnings

    public SQLWarning getWarnings()
                           throws SQLException

  The first warning reported by calls on this Connection is returned.

  Note: Subsequent warnings will be chained to this SQLWarning.

  Specified by:
    `getWarnings` in interface `Connection`
  Returns:
    the first SQLWarning or null
  Throws:
    `SQLException` - if a database access error occurs.
  Since:
    JDBC 1

### clearWarnings

    public void clearWarnings()
                       throws SQLException

  After this call, getWarnings returns null until a new warning is reported for this Connection.
  Specified by:
    `clearWarnings` in interface `Connection`
  Throws:
    `SQLException` - if a database-access error occurs.
  Since:
    JDBC 1

### createStatement

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

  Same as `createStatement()` above, but allows the default result set type and result set concurrency type to be overridden.
  Specified by:
    `createStatement` in interface `Connection`
  Parameters:
    `resultSetType` - a result set type, see ResultSet.TYPE_XXX
    `resultSetConcurrency` - a concurrency type, see ResultSet.CONCUR_XXX
  Returns:
    a new Statement object
  Throws:
    `SQLException` - if a database access error occurs.
  Since:
    JDBC 2, not yet supported

### prepareStatement

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

  Same as `prepareStatement()` above, but allows the default result set type and result set concurrency type to be overridden.
  Specified by:
    `prepareStatement` in interface `Connection`
  Parameters:
    `resultSetType` - a result set type, see ResultSet.TYPE_XXX
    `resultSetConcurrency` - a concurrency type, see ResultSet.CONCUR_XXX
  Returns:
    a new PreparedStatement object containing the pre-compiled SQL statement
  Throws:
    `SQLException` - if a database access error occurs.
  Since:
    JDBC 2, not yet supported

### prepareCall

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

  Same as the JDBC 1 `prepareCall(sql)`, but allows the default result set type and result set concurrency type to be overridden.
  Specified by:
    `prepareCall` in interface `Connection`
  Parameters:
    `resultSetType` - a result set type, see ResultSet.TYPE_XXX
    `resultSetConcurrency` - a concurrency type, see ResultSet.CONCUR_XXX
  Returns:
    a new CallableStatement object containing the pre-compiled SQL statement
  Throws:
    `SQLException` - if a database access error occurs.
  Since:
    JDBC 2, not yet supported

### getTypeMap

    public Map getTypeMap()
                   throws SQLException

  Get the type-map object associated with this connection. By default, the map returned is empty.
  Specified by:
    `getTypeMap` in interface `Connection`
  Throws:
    `SQLException` - if a database access error occurs.
  Since:
    JDBC 2, not yet supported

### setTypeMap

    public void setTypeMap(Map map)
                    throws SQLException

  Install a type-map object as the default type-map for this connection.
  Specified by:
    `setTypeMap` in interface `Connection`
  Throws:
    `SQLException` - if a database access error occurs.
  Since:
    JDBC 2, not yet supported

### setLockResolution

    public void setLockResolution(int mode)
                           throws SQLException

  Configures the transaction lock resolution protocol. The two possible modes are `LOCK_RESOLUTION_WAIT` or `LOCK_RESOLUTION_NO_WAIT`. The default resolution mode is `LOCK_RESOLUTION_WAIT`.

  Note: This method may not be called while in the middle of a transaction.

  Throws:
    `SQLException` - if a database access error occurs.
  Since:
    Extension, proposed for InterClient 3.0

### getLockResolution

    public int getLockResolution()
                          throws SQLException

  Gets this Connection's current lock resolution mode. This can be either `LOCK_RESOLUTION_WAIT` or `LOCK_RESOLUTION_NO_WAIT`.
  Returns:
    LOCK_RESOLUTION_WAIT or LOCK_RESOLUTION_NOWAIT
  Throws:
    `SQLException` - if a database access error occurs.
  Since:
    Extension, proposed for InterClient 3.0
  See Also:
    `setLockResolution(int)`

### setVersionAcknowledgement

    public void setVersionAcknowledgement(int mode)
                                   throws SQLException

  Configures a read-committed transaction to either recognize or ignore uncommitted record versions of a concurrent transaction on read. The two possible modes are `RECOGNIZE_UNCOMMITTED_RECORD_VERSIONS_ON_READ` or `IGNORE_UNCOMMITTED_RECORD_VERSIONS_ON_READ`. The default version-acknowledgement mode is `RECOGNIZE_UNCOMMITTED_RECORD_VERSIONS_ON_READ`.

  This method may not be called while in the middle of a transaction. Furthermore, this method is only applicable to read-committed transactions.

  If uncommitted record versions are acknowledged, then a transaction may only read the latest version of a row. If an uncommitted row update is pending, then the transaction will either wait on read or throw a `LockConflictException`, depending on the lock resolution mode.

  If uncommitted record versions are ignored, then the transaction can immediately read the latest committed version of a row, even if a more recent uncommitted version is pending. So uncommitted record versions of concurrent transactions are ignored on read.

  Throws:
    `SQLException` - if a database access error occurs.
  Since:
    Extension, proposed for InterClient 3.0
  See Also:
    `setLockResolution(int)`

### getVersionAcknowledgement

    public int getVersionAcknowledgement()
                                  throws SQLException

  Gets the current version-acknowledgement mode for a read-committed transaction. This can be either `RECOGNIZE_UNCOMMITTED_RECORD_VERSIONS_ON_READ` or `IGNORE_UNCOMMITTED_RECORD_VERSIONS_ON_READ`.
  Returns:
    RECOGNIZE_UNCOMMITTED_RECORD_VERSIONS_ON_READ or IGNORE_UNCOMMITTED_RECORD_VERSIONS_ON_READ
  Throws:
    `SQLException` - if a database access error occurs.
  Since:
    Extension, proposed for InterClient 3.0
  See Also:
    `setVersionAcknowledgement(int)`

### setTableLock

    public void setTableLock(String table,
                             int tableLock)
                      throws SQLException

  Specify an InterBase lock on a table. Table lock modes are given by the `TABLELOCK_*` variables.

  Note: This method may not be called while in the middle of a transaction.

  Throws:
    `SQLException` - if a database access error occurs.
  Since:
    Extension, proposed for InterClient 3.0, not yet supported

### getTableLock

    public int getTableLock(String table)
                     throws SQLException

  Gets the current table lock mode on a table for this transaction.
  Returns:
    Table lock mode TABLELOCK_* value.
  Throws:
    `SQLException` - if a database access error occurs.
  Since:
    Extension, proposed for InterClient 3.0, not yet supported

### commitRetain

    public void commitRetain()
                      throws SQLException

  Like commit but keeps your snapshot and retains your transaction context.
  Throws:
    `SQLException` - if a database access error occurs.
  Since:
    Extension, proposed for InterClient 3.0

### getTransactionId

    public int getTransactionId()
                         throws SQLException

  Get the InterBase transaction id for the current transaction.

  This is a placeholder for proposed future functionality.

  Throws:
    `SQLException` - if a database access error occurs.
  Since:
    Extension, proposed for future release, not yet supported

### inTransaction

    public boolean inTransaction()
                          throws SQLException

  Is a transaction currently active on this connection.

  This is a placeholder for proposed possible future functionality.

  Throws:
    `SQLException` - if a database access error occurs.
  Since:
    Extension, proposed for possible future release, not yet supported

### getAttachmentSQLDialect

    public int getAttachmentSQLDialect()
                                throws SQLException

  Gets this Connection's current SQL dialect. With InterBase 5 databases, this value is always 1. With InterBase 6 databases, this can be either

  1: indicating InterBase 5 compatibilty 2: indicating a transition mode 3: indicating a mode that supports all SQL features of InterBase 6

  Throws:
    `SQLException` - if a database access error occurs.
  Since:
    Extension since InterClient 2.0
  See Also:
    `DatabaseMetaData.getDatabaseSQLDialect()`

Overview | Package | Class | Tree | Deprecated | Index | Help

3.00.12
PREV CLASS NEXT CLASS | FRAMES NO FRAMES
SUMMARY: INNER | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD

Send comments or suggestions to interclient@borland.com