The java.sql
package, referred to as the JDBC 2.0 core API,
had many new features added in the
JavaTM 2 SDK, Standard Edition,
version 1.2 release. New methods, fields, constructors, and exceptions
in the JDBC 2.0 API are marked "Since 1.2" in the javadoc comments.
The class SQLPermission
was added in the
JavaTM 2 SDK, Standard Edition,
version 1.3 release. This class is used to prevent unauthorized
access to the logging stream associated with the DriverManager
,
which may contain information such as
table names, column data, and so on.
NOTE: Code that uses API marked "Since 1.2" must be run using a JDBC technology driver that implements the JDBC 2.0 core API. Check your driver documentation to be sure that it implements the particular features you want to use.
The JDBCTM 2.0 API includes the complete JDBC API, which includes both core and Optional Package API, and provides industrial-strength database computing capabilities. It is not, however, limited to SQL databases; the JDBC2.0 API makes it possible to access data from virtually any data source with a tabular format.
The JDBC 2.0 API includes two packages:
java.sql
package--the JDBC 2.0 core API
javax.sql
package--the JDBC 2.0 Optional Package API.
This package extends the functionality of the JDBC API from
a client-side API to a server-side API, and it is an essential part
of JavaTM 2 SDK, Enterprise Edition
technology.
Being an Optional Package, it is not included in the Java 2 Platform SDK, Standard Edition, version 1.2, but it is readily available from various sources.
javax.sql
package may also be downloaded from
this web site.
javax.sql
package with their products.
java.sql
Package Containsjava.sql
package contains API for the following:
DriverManager
class
Driver
interface
DriverPropertyInfo
class
Connection
interface
Statement
interface for sending basic SQL
statements
PreparedStatement
interface for sending prepared
statements or basic SQL statements (derived from
Statement
)
CallableStatement
interface for calling database
stored procedures (derived from PreparedStatement
)
ResultSet
interface
Array
interface
Blob
interface
Clob
interface
Date
class
Ref
interface
Struct
interface
Time
class
Timestamp
class
Types
class
SQLData
interface
SQLInput
interface
SQLOutput
interface
ResultSet
object
DatabaseMetaData
interface
ResultSetMetaData
interface
SQLException
thrown by most methods when there
is a problem accessing data and by some methods for other reasons
SQLWarning
thrown to indicate a warning
DataTruncation
thrown to indicate that data may have
been truncated
BatchUpdateException
thrown to indicate that not all
commands in a batch update executed successfully
SQLPermission
interface
ResultSet
interface that allow the cursor to be moved to a particular row or to a
position relative to its current position
ResultSet.updateXXX
methods
java.math.BigDecimal
values,
additional security, and
support for time zones in date, time, and timestamp values.
DISTINCT
type are the UDTs that may be custom mapped. The following three
steps set up a custom mapping:
DISTINCT
type in SQL
SQLData
interface.
Connection
object's type map
that contains two things:
Class
object for the class to which the UDT is to
be mapped
When these are in place for a UDT, calling the methods
ResultSet.getObject
or CallableStatement.getObject
on that UDT will automatically retrieve the custom mapping for it.
Connection
object 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 {@link 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);
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.readXXX
methods to read
each attribute from an SQLInput
object, and the
writeSQL
method calls SQLOutput.writeXXX
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.