The mapping in the Java programming language for the SQL type
ARRAY.
By default, an Array value is a transaction-duration
reference to an SQL ARRAY value.  By default, an Array
object is implemented using an SQL LOCATOR(array) internally, which
means that an Array object contains a logical pointer
to the data in the SQL ARRAY value rather
than containing the ARRAY value's data.

The Array interface provides methods for bringing an SQL
ARRAY value's data to the client as either an array or a
ResultSet object.
If the elements of the SQL ARRAY
are a UDT, they may be custom mapped.  To create a custom mapping,
a programmer must do two things:

create a class that implements the SQLData
interface for the UDT to be custom mapped.
make an entry in a type map that contains

  the fully-qualified SQL type name of the UDT
  the Class object for the class implementing
      SQLData



When a type map with an entry for
the base type is supplied to the methods getArray
and getResultSet, the mapping
it contains will be used to map the elements of the ARRAY value.
If no type map is supplied, which would typically be the case,
the connection's type map is used by default.
If the connection's type map or a type map supplied to a method has no entry
for the base type, the elements are mapped according to the standard mapping.

All methods on the Array interface must be fully implemented if the
JDBC driver supports the data type.

The subclass of SQLException thrown when an error
occurs during a batch update operation.  In addition to the
information provided by SQLException, a
BatchUpdateException provides the update
counts for all commands that were executed successfully during the
batch update, that is, all commands that were executed before the error
occurred.  The order of elements in an array of update counts
corresponds to the order in which commands were added to the batch.

After a command in a batch update fails to execute properly
and a BatchUpdateException is thrown, the driver
may or may not continue to process the remaining commands in
the batch.  If the driver continues processing after a failure,
the array returned by the method
BatchUpdateException.getUpdateCounts will have
an element for every command in the batch rather than only
elements for the commands that executed successfully before
the error.  In the case where the driver continues processing
commands, the array element for any command
that failed is Statement.EXECUTE_FAILED.

A JDBC driver implementation should use
the constructor BatchUpdateException(String reason, String SQLState,
int vendorCode, long []updateCounts,Throwable cause)  instead of
constructors that take int[] for the update counts to avoid the
possibility of overflow.

If Statement.executeLargeBatch method is invoked it is recommended that
getLargeUpdateCounts be called instead of getUpdateCounts
in order to avoid a possible overflow of the integer update count.

The representation (mapping) in
the Java™ programming
language of an SQL
BLOB value.  An SQL BLOB is a built-in type
that stores a Binary Large Object as a column value in a row of
a database table. By default drivers implement Blob using
an SQL locator(BLOB), which means that a
Blob object contains a logical pointer to the
SQL BLOB data rather than the data itself.
A Blob object is valid for the duration of the
transaction in which is was created.

Methods in the interfaces ResultSet,
CallableStatement, and PreparedStatement, such as
getBlob and setBlob allow a programmer to
access an SQL BLOB value.
The Blob interface provides methods for getting the
length of an SQL BLOB (Binary Large Object) value,
for materializing a BLOB value on the client, and for
determining the position of a pattern of bytes within a
BLOB value. In addition, this interface has methods for updating
a BLOB value.

All methods on the Blob interface must be fully implemented if the
JDBC driver supports the data type.

The interface used to execute SQL stored procedures.  The JDBC API
provides a stored procedure SQL escape syntax that allows stored procedures
to be called in a standard way for all RDBMSs. This escape syntax has one
form that includes a result parameter and one that does not. If used, the result
parameter must be registered as an OUT parameter. The other parameters
can be used for input, output or both. Parameters are referred to
sequentially, by number, with the first parameter being 1.


  {?= call <procedure-name>[(<arg1>,<arg2>, ...)]}
  {call <procedure-name>[(<arg1>,<arg2>, ...)]}

IN parameter values are set using the set methods inherited from
PreparedStatement.  The type of all OUT parameters must be
registered prior to executing the stored procedure; their values
are retrieved after execution via the get methods provided here.

A CallableStatement can return one ResultSet object or
multiple ResultSet objects.  Multiple
ResultSet objects are handled using operations
inherited from Statement.

For maximum portability, a call's ResultSet objects and
update counts should be processed prior to getting the values of output
parameters.

The mapping in the Java™ programming language
for the SQL CLOB type.
An SQL CLOB is a built-in type
that stores a Character Large Object as a column value in a row of
a database table.
By default drivers implement a Clob object using an SQL
locator(CLOB), which means that a Clob object
contains a logical pointer to the SQL CLOB data rather than
the data itself. A Clob object is valid for the duration
of the transaction in which it was created.
The Clob interface provides methods for getting the
length of an SQL CLOB (Character Large Object) value,
for materializing a CLOB value on the client, and for
searching for a substring or CLOB object within a
CLOB value.
Methods in the interfaces ResultSet,
CallableStatement, and PreparedStatement, such as
getClob and setClob allow a programmer to
access an SQL CLOB value.  In addition, this interface
has methods for updating a CLOB value.

All methods on the Clob interface must be fully implemented if the
JDBC driver supports the data type.

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

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

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

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

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

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

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


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

Comprehensive information about the database as a whole.

This interface is implemented by driver vendors to let users know the capabilities
of a Database Management System (DBMS) in combination with
the driver based on JDBC™ technology
("JDBC driver") that is used with it.  Different relational DBMSs often support
different features, implement features in different ways, and use different
data types.  In addition, a driver may implement a feature on top of what the
DBMS offers.  Information returned by methods in this interface applies
to the capabilities of a particular driver and a particular DBMS working
together. Note that as used in this documentation, the term "database" is
used generically to refer to both the driver and DBMS.

A user for this interface is commonly a tool that needs to discover how to
deal with the underlying DBMS.  This is especially true for applications
that are intended to be used with more than one DBMS. For example, a tool might use the method
getTypeInfo to find out what data types can be used in a
CREATE TABLE statement.  Or a user might call the method
supportsCorrelatedSubqueries to see if it is possible to use
a correlated subquery or supportsBatchUpdates to see if it is
possible to use batch updates.

Some DatabaseMetaData methods return lists of information
in the form of ResultSet objects.
Regular ResultSet methods, such as
getString and getInt, can be used
to retrieve the data from these ResultSet objects.  If
a given form of metadata is not available, an empty ResultSet
will be returned. Additional columns beyond the columns defined to be
returned by the ResultSet object for a given method
can be defined by the JDBC driver vendor and must be accessed
by their column label.

Some DatabaseMetaData methods take arguments that are
String patterns.  These arguments all have names such as fooPattern.
Within a pattern String, "%" means match any substring of 0 or more
characters, and "_" means match any one character. Only metadata
entries matching the search pattern are returned. If a search pattern
argument is set to null, that argument's criterion will
be dropped from the search.

An exception  thrown as a DataTruncation exception
(on writes) or reported as a
DataTruncation warning (on reads)
 when a data values is unexpectedly truncated for reasons other than its having
 exceeded MaxFieldSize.

The SQLstate for a DataTruncation during read is 01004.
The SQLstate for a DataTruncation during write is 22001.

A thin wrapper around a millisecond value that allows
JDBC to identify this as an SQL DATE value.  A
milliseconds value represents the number of milliseconds that
have passed since January 1, 1970 00:00:00.000 GMT.

To conform with the definition of SQL DATE, the
millisecond values wrapped by a java.sql.Date instance
must be 'normalized' by setting the
hours, minutes, seconds, and milliseconds to zero in the particular
time zone with which the instance is associated.

The interface that every driver class must implement.
The Java SQL framework allows for multiple database drivers.

Each driver should supply a class that implements
the Driver interface.

The DriverManager will try to load as many drivers as it can
find and then for any given connection request, it will ask each
driver in turn to try to connect to the target URL.

It is strongly recommended that each Driver class should be
small and standalone so that the Driver class can be loaded and
queried without bringing in vast quantities of supporting code.

When a Driver class is loaded, it should create an instance of
itself and register it with the DriverManager. This means that a
user can load and register a driver by calling:

Class.forName("foo.bah.Driver")

A JDBC driver may create a java.sql.DriverAction implementation in order
to receive notifications when DriverManager.deregisterDriver(java.sql.Driver) has
been called.

An interface that must be implemented when a java.sql.Driver wants to be
notified by DriverManager.

A DriverAction implementation is not intended to be used
directly by applications. A JDBC Driver  may choose
to create its DriverAction implementation in a private class
to avoid it being called directly.

The JDBC driver's static initialization block must call
DriverManager.registerDriver(java.sql.Driver, java.sql.DriverAction) in order
to inform DriverManager which DriverAction implementation to
call when the JDBC driver is de-registered.

The basic service for managing a set of JDBC drivers.
NOTE: The DataSource interface, new in the
JDBC 2.0 API, provides another way to connect to a data source.
The use of a DataSource object is the preferred means of
connecting to a data source.

As part of its initialization, the DriverManager class will
attempt to load the driver classes referenced in the "jdbc.drivers"
system property. This allows a user to customize the JDBC Drivers
used by their applications. For example in your
~/.hotjava/properties file you might specify:


jdbc.drivers=foo.bah.Driver:wombat.sql.Driver:bad.taste.ourDriver
The DriverManager methods getConnection and
getDrivers have been enhanced to support the Java Standard Edition
Service Provider mechanism. JDBC 4.0 Drivers must
include the file META-INF/services/java.sql.Driver. This file contains the name of the JDBC drivers
implementation of java.sql.Driver.  For example, to load the my.sql.Driver class,
the META-INF/services/java.sql.Driver file would contain the entry:


my.sql.Driver

Applications no longer need to explicitly load JDBC drivers using Class.forName(). Existing programs
which currently load JDBC drivers using Class.forName() will continue to work without
modification.

When the method getConnection is called,
the DriverManager will attempt to
locate a suitable driver from amongst those loaded at
initialization and those loaded explicitly using the same classloader
as the current applet or application.


Starting with the Java 2 SDK, Standard Edition, version 1.3, a
logging stream can be set only if the proper
permission has been granted.  Normally this will be done with
the tool PolicyTool, which can be used to grant permission
java.sql.SQLPermission "setLog".

Driver properties for making a connection. The
DriverPropertyInfo class is of interest only to advanced programmers
who need to interact with a Driver via the method
getDriverProperties to discover
and supply properties for connections.

The mapping in the Java™ programming language
for the SQL NCLOB type.
An SQL NCLOB is a built-in type
that stores a Character Large Object using the National Character Set
 as a column value in a row of  a database table.
The NClob interface extends the Clob interface
which provides provides methods for getting the
length of an SQL NCLOB value,
for materializing a NCLOB value on the client, and for
searching for a substring or NCLOB object within a
NCLOB value. A NClob object, just like a Clob object, is valid for the duration
of the transaction in which it was created.
Methods in the interfaces ResultSet,
CallableStatement, and PreparedStatement, such as
getNClob and setNClob allow a programmer to
access an SQL NCLOB value.  In addition, this interface
has methods for updating a NCLOB value.

All methods on the NClob interface must be fully implemented if the
JDBC driver supports the data type.

An object that can be used to get information about the types
 and properties for each parameter marker in a
 PreparedStatement object. For some queries and driver
 implementations, the data that would be returned by a ParameterMetaData
 object may not be available until the PreparedStatement has
 been executed.

Some driver implementations may not be able to provide information about the
types and properties for each parameter marker in a CallableStatement
object.

An object that represents a precompiled SQL statement.
A SQL statement is precompiled and stored in a
PreparedStatement object. This object can then be used to
efficiently execute this statement multiple times.

Note: The setter methods (setShort, setString,
and so on) for setting IN parameter values
must specify types that are compatible with the defined SQL type of
the input parameter. For instance, if the IN parameter has SQL type
INTEGER, then the method setInt should be used.

If arbitrary parameter type conversions are required, the method
setObject should be used with a target SQL type.

In the following example of setting a parameter, con represents
an active connection:


  PreparedStatement pstmt = con.prepareStatement("UPDATE EMPLOYEES
                                    SET SALARY = ? WHERE ID = ?");
  pstmt.setBigDecimal(1, 153833.00)
  pstmt.setInt(2, 110592)

The mapping in the Java programming language of an SQL REF
value, which is a reference to an SQL structured type value in the database.

SQL REF values are stored in a table that contains
instances of a referenceable SQL structured type, and each REF
value is a unique identifier for one instance in that table.
An SQL REF value may be used in place of the
SQL structured type it references, either as a column value in a
table or an attribute value in a structured type.

Because an SQL REF value is a logical pointer to an
SQL structured type, a Ref object is by default also a logical
pointer. Thus, retrieving an SQL REF value as
a Ref object does not materialize
the attributes of the structured type on the client.

A Ref object can be stored in the database using the
PreparedStatement.setRef method.

All methods on the Ref interface must be fully implemented if the
JDBC driver supports the data type.

  Statement stmt = con.createStatement(
                                 ResultSet.TYPE_SCROLL_INSENSITIVE,
                                 ResultSet.CONCUR_UPDATABLE);
  ResultSet rs = stmt.executeQuery("SELECT a, b FROM TABLE2");
  // rs will be scrollable, will not show changes made by others,
  // and will be updatable

  rs.absolute(5); // moves the cursor to the fifth row of rs
  rs.updateString("NAME", "AINSWORTH"); // updates the
     // NAME column of row 5 to be AINSWORTH
  rs.updateRow(); // updates the row in the data source

  rs.moveToInsertRow(); // moves cursor to the insert row
  rs.updateString(1, "AINSWORTH"); // updates the
     // first column of the insert row to be AINSWORTH
  rs.updateInt(2,35); // updates the second column to be 35
  rs.updateBoolean(3, true); // updates the third column to true
  rs.insertRow();
  rs.moveToCurrentRow();

A table of data representing a database result set, which
is usually generated by executing a statement that queries the database.

A ResultSet object  maintains a cursor pointing
to its current row of data.  Initially the cursor is positioned
before the first row. The next method moves the
cursor to the next row, and because it returns false
when there are no more rows in the ResultSet object,
it can be used in a while loop to iterate through
the result set.

A default ResultSet object is not updatable and
has a cursor that moves forward only.  Thus, you can
iterate through it only once and only from the first row to the
last row. It is possible to
produce ResultSet objects that are scrollable and/or
updatable.  The following code fragment, in which con
is a valid Connection object, illustrates how to make
a result set that is scrollable and insensitive to updates by others, and
that is updatable. See ResultSet fields for other
options.


      Statement stmt = con.createStatement(
                                     ResultSet.TYPE_SCROLL_INSENSITIVE,
                                     ResultSet.CONCUR_UPDATABLE);
      ResultSet rs = stmt.executeQuery("SELECT a, b FROM TABLE2");
      // rs will be scrollable, will not show changes made by others,
      // and will be updatable
The ResultSet interface provides
getter methods (getBoolean, getLong, and so on)
for retrieving column values from the current row.
Values can be retrieved using either the index number of the
column or the name of the column.  In general, using the
column index will be more efficient.  Columns are numbered from 1.
For maximum portability, result set columns within each row should be
read in left-to-right order, and each column should be read only once.

For the getter methods, a JDBC driver attempts
to convert the underlying data to the Java type specified in the
getter method and returns a suitable Java value.  The JDBC specification
has a table showing the allowable mappings from SQL types to Java types
that can be used by the ResultSet getter methods.

Column names used as input to getter methods are case
insensitive.  When a getter method is called  with
a column name and several columns have the same name,
the value of the first matching column will be returned.
The column name option is
designed to be used when column names are used in the SQL
query that generated the result set.
For columns that are NOT explicitly named in the query, it
is best to use column numbers. If column names are used, the
programmer should take care to guarantee that they uniquely refer to
the intended columns, which can be assured with the SQL AS clause.

A set of updater methods were added to this interface
in the JDBC 2.0 API (Java™ 2 SDK,
Standard Edition, version 1.2). The comments regarding parameters
to the getter methods also apply to parameters to the
updater methods.

The updater methods may be used in two ways:

to update a column value in the current row.  In a scrollable
    ResultSet object, the cursor can be moved backwards
    and forwards, to an absolute position, or to a position
    relative to the current row.
    The following code fragment updates the NAME column
    in the fifth row of the ResultSet object
    rs and then uses the method updateRow
    to update the data source table from which rs was derived.


      rs.absolute(5); // moves the cursor to the fifth row of rs
      rs.updateString("NAME", "AINSWORTH"); // updates the
         // NAME column of row 5 to be AINSWORTH
      rs.updateRow(); // updates the row in the data source
to insert column values into the insert row.  An updatable
    ResultSet object has a special row associated with
    it that serves as a staging area for building a row to be inserted.
    The following code fragment moves the cursor to the insert row, builds
    a three-column row, and inserts it into rs and into
    the data source table using the method insertRow.


      rs.moveToInsertRow(); // moves cursor to the insert row
      rs.updateString(1, "AINSWORTH"); // updates the
         // first column of the insert row to be AINSWORTH
      rs.updateInt(2,35); // updates the second column to be 35
      rs.updateBoolean(3, true); // updates the third column to true
      rs.insertRow();
      rs.moveToCurrentRow();

A ResultSet object is automatically closed when the
Statement object that
generated it is closed, re-executed, or used
to retrieve the next result from a sequence of multiple results.

The number, types and properties of a ResultSet
object's columns are provided by the ResultSetMetaData
object returned by the ResultSet.getMetaData method.

ResultSet rs = stmt.executeQuery("SELECT a, b, c FROM TABLE2");
ResultSetMetaData rsmd = rs.getMetaData();
int numberOfColumns = rsmd.getColumnCount();
boolean b = rsmd.isSearchable(1);

An object that can be used to get information about the types
and properties of the columns in a ResultSet object.
The following code fragment creates the ResultSet object rs,
creates the ResultSetMetaData object rsmd, and uses rsmd
to find out how many columns rs has and whether the first column in rs
can be used in a WHERE clause.


    ResultSet rs = stmt.executeQuery("SELECT a, b, c FROM TABLE2");
    ResultSetMetaData rsmd = rs.getMetaData();
    int numberOfColumns = rsmd.getColumnCount();
    boolean b = rsmd.isSearchable(1);

The representation (mapping) in the Java programming language of an SQL ROWID
value. An SQL ROWID is a built-in type, a value of which can be thought of as
an address  for its identified row in a database table. Whether that address
is logical or, in any  respects, physical is determined by its originating data
source.

Methods in the interfaces ResultSet, CallableStatement,
and PreparedStatement, such as getRowId and setRowId
allow a programmer to access a SQL ROWID  value. The RowId
interface provides a method
for representing the value of the ROWID as a byte array or as a
String.

The method getRowIdLifetime in the interface DatabaseMetaData,
can be used
to determine if a RowId object remains valid for the duration of the transaction in
which  the RowId was created, the duration of the session in which
the RowId was created,
or, effectively, for as long as its identified row is not deleted. In addition
to specifying the duration of its valid lifetime outside its originating data
source, getRowIdLifetime specifies the duration of a ROWID
value's valid lifetime
within its originating data source. In this, it differs from a large object,
because there is no limit on the valid lifetime of a large  object within its
originating data source.

All methods on the RowId interface must be fully implemented if the
JDBC driver supports the data type.

The representation of a savepoint, which is a point within
the current transaction that can be referenced from the
Connection.rollback method. When a transaction
is rolled back to a savepoint all changes made after that
savepoint are undone.

Savepoints can be either named or unnamed. Unnamed savepoints
are identified by an ID generated by the underlying data source.

The subclass of SQLException is thrown when one or more client info properties
could not be set on a Connection.  In addition to the information provided
by SQLException, a SQLClientInfoException provides a list of client info
properties that were not set.

Some databases do not allow multiple client info properties to be set
atomically.  For those databases, it is possible that some of the client
info properties had been set even though the Connection.setClientInfo
method threw an exception.  An application can use the getFailedProperties
method to retrieve a list of client info properties that were not set.  The
properties are identified by passing a
Map<String,ClientInfoStatus> to
the appropriate SQLClientInfoException constructor.

The interface used for the custom mapping of an SQL user-defined type (UDT) to
a class in the Java programming language. The class object for a class
implementing the SQLData interface will be entered in the
appropriate Connection object's type map along with the SQL
name of the UDT for which it is a custom mapping.

Typically, a SQLData implementation
will define a field for each attribute of an SQL structured type or a
single field for an SQL DISTINCT type. When the UDT is
retrieved from a data source with the ResultSet.getObject
method, it will be mapped as an instance of this class.  A programmer
can operate on this class instance just as on any other object in the
Java programming language and then store any changes made to it by
calling the PreparedStatement.setObject method,
which will map it back to the SQL type.

It is expected that the implementation of the class for a custom
mapping will be done by a tool.  In a typical implementation, the
programmer would simply supply the name of the SQL UDT, the name of
the class to which it is being mapped, and the names of the fields to
which each of the attributes of the UDT is to be mapped.  The tool will use
this information to implement the SQLData.readSQL and
SQLData.writeSQL methods.  The readSQL method
calls the appropriate SQLInput methods to read
each attribute from an SQLInput object, and the
writeSQL method calls SQLOutput methods
to write each attribute back to the data source via an
SQLOutput object.

An application programmer will not normally call SQLData methods
directly, and the SQLInput and SQLOutput methods
are called internally by SQLData methods, not by application code.

The subclass of SQLException thrown when the SQLState class value
is '22', or under vendor-specified conditions.  This indicates
various data errors, including but not limited to data conversion errors,
division by 0, and invalid arguments to functions.

Please consult your driver vendor documentation for the vendor-specified
conditions for which this Exception may be thrown.

An exception that provides information on a database access
error or other errors.

Each SQLException provides several kinds of information:

   a string describing the error.  This is used as the Java Exception
      message, available via the method getMesasge.
   a "SQLstate" string, which follows either the XOPEN SQLstate conventions
       or the SQL:2003 conventions.
      The values of the SQLState string are described in the appropriate spec.
      The DatabaseMetaData method getSQLStateType
      can be used to discover whether the driver returns the XOPEN type or
      the SQL:2003 type.
   an integer error code that is specific to each vendor.  Normally this will
      be the actual error code returned by the underlying database.
   a chain to a next Exception.  This can be used to provide additional
      error information.
   the causal relationship, if any for this SQLException.

The subclass of SQLException thrown when the SQLState class value is '0A'
 ( the value is 'zero' A).
 This indicates that the JDBC driver does not support an optional JDBC feature.
 Optional JDBC features can fall into the fallowing categories:


no support for an optional feature
no support for an optional overloaded method
no support for an optional mode for a method.  The mode for a method is
determined based on constants passed as parameter values to a method

An input stream that contains a stream of values representing an
instance of an SQL structured type or an SQL distinct type.
This interface, used only for custom mapping, is used by the driver
behind the scenes, and a programmer never directly invokes
SQLInput methods. The reader methods
(readLong, readBytes, and so on)
provide a way  for an implementation of the SQLData
 interface to read the values in an SQLInput object.
 And as described in SQLData, calls to reader methods must
be made in the order that their corresponding attributes appear in the
SQL definition of the type.
The method wasNull is used to determine whether
the last value read was SQL NULL.
When the method getObject is called with an
object of a class implementing the interface SQLData,
the JDBC driver calls the method SQLData.getSQLType
to determine the SQL type of the user-defined type (UDT)
being custom mapped. The driver
creates an instance of SQLInput, populating it with the
attributes of the UDT.  The driver then passes the input
stream to the method SQLData.readSQL, which in turn
calls the SQLInput reader methods
in its implementation for reading the
attributes from the input stream.

The subclass of SQLException thrown when the SQLState class value
is '23', or under vendor-specified conditions.
This indicates that an integrity
constraint (foreign key, primary key or unique key) has been violated.

Please consult your driver vendor documentation for the vendor-specified
conditions for which this Exception may be thrown.

The subclass of SQLException thrown when the SQLState class value
is '28', or under vendor-specified conditions. This indicates that
the authorization credentials presented during connection establishment
are not valid.

Please consult your driver vendor documentation for the vendor-specified
conditions for which this Exception may be thrown.

The subclass of SQLException thrown for the SQLState
class value '08', or under vendor-specified conditions.  This
indicates that the connection operation that failed will not succeed if
the operation is retried without the cause of the failure being corrected.

Please consult your driver vendor documentation for the vendor-specified
conditions for which this Exception may be thrown.

The subclass of SQLException thrown when an instance where a retry
of the same operation would fail unless the cause of the SQLException
is corrected.

The output stream for writing the attributes of a user-defined
type back to the database.  This interface, used
only for custom mapping, is used by the driver, and its
methods are never directly invoked by a programmer.
When an object of a class implementing the interface
SQLData is passed as an argument to an SQL statement, the
JDBC driver calls the method SQLData.getSQLType to
determine the  kind of SQL
datum being passed to the database.
The driver then creates an instance of SQLOutput and
passes it to the method SQLData.writeSQL.
The method writeSQL in turn calls the
appropriate SQLOutput writer methods
writeBoolean, writeCharacterStream, and so on)
to write data from the SQLData object to
the SQLOutput output stream as the
representation of an SQL user-defined type.

The permission for which the SecurityManager will check
when code that is running an application with a
SecurityManager enabled, calls the
DriverManager.deregisterDriver method,
DriverManager.setLogWriter method,
DriverManager.setLogStream (deprecated) method,
SyncFactory.setJNDIContext method,
SyncFactory.setLogger method,
Connection.setNetworktimeout method,
or the Connection.abort method.
If there is no SQLPermission object, these methods
throw a java.lang.SecurityException as a runtime exception.

A SQLPermission object contains
a name (also referred to as a "target name") but no actions
list; there is either a named permission or there is not.
The target name is the name of the permission (see below). The
naming convention follows the  hierarchical property naming convention.
In addition, an asterisk
may appear at the end of the name, following a ".", or by itself, to
signify a wildcard match. For example: loadLibrary.*
and * signify a wildcard match,
while *loadLibrary and a*b do not.

The following table lists all the possible SQLPermission target names.
The table gives a description of what the permission allows
and a discussion of the risks of granting code the permission.




Permission Target Name
What the Permission Allows
Risks of Allowing this Permission



  setLog
  Setting of the logging stream
  This is a dangerous permission to grant.
The contents of the log may contain usernames and passwords,
SQL statements, and SQL data.


callAbort
  Allows the invocation of the Connection method
  abort
  Permits an application to terminate a physical connection to a
 database.


setSyncFactory
  Allows the invocation of the SyncFactory methods
  setJNDIContext and setLogger
  Permits an application to specify the JNDI context from which the
  SyncProvider implementations can be retrieved from and the logging
  object to be used by the SyncProvider implementation.



setNetworkTimeout
  Allows the invocation of the Connection method
  setNetworkTimeout
  Permits an application to specify the maximum period a
Connection or
objects created from the Connection
will wait for the database to reply to any one request.

deregisterDriver
  Allows the invocation of the DriverManager
method deregisterDriver
  Permits an application to remove a JDBC driver from the list of
registered Drivers and release its resources.

The subclass of SQLException thrown in situations where a
previously failed operation might be able to succeed if the application performs
 some recovery steps and retries the entire transaction or in the case of a
distributed transaction, the transaction branch.  At a minimum,
the recovery operation must include closing the current connection and getting
a new connection.

The subclass of SQLException thrown when the SQLState class value
is '42', or under vendor-specified conditions. This indicates that the
in-progress query has violated SQL syntax rules.

Please consult your driver vendor documentation for the vendor-specified
conditions for which this Exception may be thrown.

The subclass of SQLException thrown when the timeout specified by
Statement.setQueryTimeout, DriverManager.setLoginTimeout,
DataSource.setLoginTimeout,XADataSource.setLoginTimeout
has expired.
 This exception does not correspond to a standard SQLState.

The subclass of SQLException thrown when the SQLState class value
is '40', or under vendor-specified conditions. This indicates that the
current statement was automatically rolled back by the database because
of deadlock or other transaction serialization failures.

Please consult your driver vendor documentation for the vendor-specified
conditions for which this Exception may be thrown.

The subclass of SQLException for the SQLState class
value '08', or under vendor-specified conditions.  This indicates
that the connection operation that failed might be able to succeed if
the operation is retried without any application-level changes.

Please consult your driver vendor documentation for the vendor-specified
conditions for which this Exception may be thrown.

The subclass of SQLException is thrown in situations where a
previously failed operation might be able to succeed when the operation is
retried without any intervention by application-level functionality.

An object that is used to identify a generic SQL type, called a JDBC type or
a vendor specific data type.

An exception that provides information on  database access
warnings. Warnings are silently chained to the object whose method
caused it to be reported.

Warnings may be retrieved from Connection, Statement,
and ResultSet objects.  Trying to retrieve a warning on a
connection after it has been closed will cause an exception to be thrown.
Similarly, trying to retrieve a warning on a statement after it has been
closed or on a result set after it has been closed will cause
an exception to be thrown. Note that closing a statement also
closes a result set that it might have produced.

The mapping in the JavaTM programming language for the SQL XML type.
XML is a built-in type that stores an XML value
as a column value in a row of a database table.
By default drivers implement an SQLXML object as
a logical pointer to the XML data
rather than the data itself.
An SQLXML object is valid for the duration of the transaction in which it was created.

The SQLXML interface provides methods for accessing the XML value
as a String, a Reader or Writer, or as a Stream.  The XML value
may also be accessed through a Source or set as a Result, which
are used with XML Parser APIs such as DOM, SAX, and StAX, as
well as with XSLT transforms and XPath evaluations.

Methods in the interfaces ResultSet, CallableStatement, and PreparedStatement,
such as getSQLXML allow a programmer to access an XML value.
In addition, this interface has methods for updating an XML value.

The XML value of the SQLXML instance may be obtained as a BinaryStream using


  SQLXML sqlxml = resultSet.getSQLXML(column);
  InputStream binaryStream = sqlxml.getBinaryStream();
For example, to parse an XML value with a DOM parser:


  DocumentBuilder parser = DocumentBuilderFactory.newInstance().newDocumentBuilder();
  Document result = parser.parse(binaryStream);
or to parse an XML value with a SAX parser to your handler:


  SAXParser parser = SAXParserFactory.newInstance().newSAXParser();
  parser.parse(binaryStream, myHandler);
or to parse an XML value with a StAX parser:


  XMLInputFactory factory = XMLInputFactory.newInstance();
  XMLStreamReader streamReader = factory.createXMLStreamReader(binaryStream);

Because databases may use an optimized representation for the XML,
accessing the value through getSource() and
setResult() can lead to improved processing performance
without serializing to a stream representation and parsing the XML.

For example, to obtain a DOM Document Node:


  DOMSource domSource = sqlxml.getSource(DOMSource.class);
  Document document = (Document) domSource.getNode();
or to set the value to a DOM Document Node to myNode:


  DOMResult domResult = sqlxml.setResult(DOMResult.class);
  domResult.setNode(myNode);
or, to send SAX events to your handler:


  SAXSource saxSource = sqlxml.getSource(SAXSource.class);
  XMLReader xmlReader = saxSource.getXMLReader();
  xmlReader.setContentHandler(myHandler);
  xmlReader.parse(saxSource.getInputSource());
or, to set the result value from SAX events:


  SAXResult saxResult = sqlxml.setResult(SAXResult.class);
  ContentHandler contentHandler = saxResult.getHandler();
  contentHandler.startDocument();
  // set the XML elements and attributes into the result
  contentHandler.endDocument();
or, to obtain StAX events:


  StAXSource staxSource = sqlxml.getSource(StAXSource.class);
  XMLStreamReader streamReader = staxSource.getXMLStreamReader();
or, to set the result value from StAX events:


  StAXResult staxResult = sqlxml.setResult(StAXResult.class);
  XMLStreamWriter streamWriter = staxResult.getXMLStreamWriter();
or, to perform XSLT transformations on the XML value using the XSLT in xsltFile
output to file resultFile:


  File xsltFile = new File("a.xslt");
  File myFile = new File("result.xml");
  Transformer xslt = TransformerFactory.newInstance().newTransformer(new StreamSource(xsltFile));
  Source source = sqlxml.getSource(null);
  Result result = new StreamResult(myFile);
  xslt.transform(source, result);
or, to evaluate an XPath expression on the XML value:


  XPath xpath = XPathFactory.newInstance().newXPath();
  DOMSource domSource = sqlxml.getSource(DOMSource.class);
  Document document = (Document) domSource.getNode();
  String expression = "/foo/@bar";
  String barValue = xpath.evaluate(expression, document);
To set the XML value to be the result of an XSLT transform:


  File sourceFile = new File("source.xml");
  Transformer xslt = TransformerFactory.newInstance().newTransformer(new StreamSource(xsltFile));
  Source streamSource = new StreamSource(sourceFile);
  Result result = sqlxml.setResult(null);
  xslt.transform(streamSource, result);
Any Source can be transformed to a Result using the identity transform
specified by calling newTransformer():


  Transformer identity = TransformerFactory.newInstance().newTransformer();
  Source source = sqlxml.getSource(null);
  File myFile = new File("result.xml");
  Result result = new StreamResult(myFile);
  identity.transform(source, result);
To write the contents of a Source to standard output:


  Transformer identity = TransformerFactory.newInstance().newTransformer();
  Source source = sqlxml.getSource(null);
  Result result = new StreamResult(System.out);
  identity.transform(source, result);
To create a DOMSource from a DOMResult:


   DOMSource domSource = new DOMSource(domResult.getNode());

Incomplete or invalid XML values may cause an SQLException when
set or the exception may occur when execute() occurs.  All streams
must be closed before execute() occurs or an SQLException will be thrown.

Reading and writing XML values to or from an SQLXML object can happen at most once.
The conceptual states of readable and not readable determine if one
of the reading APIs will return a value or throw an exception.
The conceptual states of writable and not writable determine if one
of the writing APIs will set a value or throw an exception.

The state moves from readable to not readable once free() or any of the
reading APIs are called: getBinaryStream(), getCharacterStream(), getSource(), and getString().
Implementations may also change the state to not writable when this occurs.

The state moves from writable to not writeable once free() or any of the
writing APIs are called: setBinaryStream(), setCharacterStream(), setResult(), and setString().
Implementations may also change the state to not readable when this occurs.


All methods on the SQLXML interface must be fully implemented if the
JDBC driver supports the data type.

The object used for executing a static SQL statement
and returning the results it produces.

By default, only one ResultSet object per Statement
object can be open at the same time. Therefore, if the reading of one
ResultSet object is interleaved
with the reading of another, each must have been generated by
different Statement objects. All execution methods in the
Statement interface implicitly close a current
ResultSet object of the statement if an open one exists.

The standard mapping in the Java programming language for an SQL
structured type. A Struct object contains a
value for each attribute of the SQL structured type that
it represents.
By default, an instance ofStruct is valid as long as the
application has a reference to it.

All methods on the Struct interface must be fully implemented if the
JDBC driver supports the data type.

A thin wrapper around the java.util.Date class that allows the JDBC
API to identify this as an SQL TIME value. The Time
class adds formatting and
parsing operations to support the JDBC escape syntax for time
values.
The date components should be set to the "zero epoch"
value of January 1, 1970 and should not be accessed.

A thin wrapper around java.util.Date that allows
the JDBC API to identify this as an SQL TIMESTAMP value.
It adds the ability
to hold the SQL TIMESTAMP fractional seconds value, by allowing
the specification of fractional seconds to a precision of nanoseconds.
A Timestamp also provides formatting and
parsing operations to support the JDBC escape syntax for timestamp values.

The precision of a Timestamp object is calculated to be either:

19 , which is the number of characters in yyyy-mm-dd hh:mm:ss
  20  s , which is the number
of characters in the yyyy-mm-dd hh:mm:ss.[fff...] and s represents  the scale of the given Timestamp,
its fractional seconds precision.


Note: This type is a composite of a java.util.Date and a
separate nanoseconds value. Only integral seconds are stored in the
java.util.Date component. The fractional seconds - the nanos - are
separate.  The Timestamp.equals(Object) method never returns
true when passed an object
that isn't an instance of java.sql.Timestamp,
because the nanos component of a date is unknown.
As a result, the Timestamp.equals(Object)
method is not symmetric with respect to the
java.util.Date.equals(Object)
method.  Also, the hashCode method uses the underlying
java.util.Date
implementation and therefore does not include nanos in its computation.

Due to the differences between the Timestamp class
and the java.util.Date
class mentioned above, it is recommended that code not view
Timestamp values generically as an instance of
java.util.Date.  The
inheritance relationship between Timestamp
and java.util.Date really
denotes implementation inheritance, and not type inheritance.

The class that defines the constants that are used to identify generic
SQL types, called JDBC types.

This class is never instantiated.

Interface for JDBC classes which provide the ability to retrieve the delegate instance when the instance
in question is in fact a proxy class.

The wrapper pattern is employed by many JDBC driver implementations to provide extensions beyond
the traditional JDBC API that are specific to a data source. Developers may wish to gain access to
these resources that are wrapped (the delegates) as  proxy class instances representing the
the actual resources. This interface describes a standard mechanism to access
these wrapped resources
represented by their proxy, to permit direct access to the resource delegates.