Javasoft JDBC: A Java SQL Api: Please Send Technical Comments On This Specification To
Javasoft JDBC: A Java SQL Api: Please Send Technical Comments On This Specification To
This is the specification for the JDBC API, which is a Java application programming in-
terface to SQL databases.
RESTRICTED RIGHTS: Use, duplication or disclosure by the government is subject to the re-
strictions as set forth in subparagraph (c) (1) (ii) of the Rights in Technical Data and Computer
Software Clause as DFARS 252.227-7013 and FAR 52.227-19.
Sun, Sun Microsystems, the Sun logo, Java, JavaSoft, JDBC, and JDBC COMPLIANT are
trademarks or registered trademarks of Sun Microsystems, Inc.
Contents
1 Introduction 4
5 Security considerations 13
6 Database connections 16
10 Cursors 33
11 SQL Extensions 34
1 Introduction
Many vendors and customers are now looking for easy database access for Java applications.
Since Java is robust, secure, easy to use, easy to understand, and automatically downloadable
on a network, it is an excellent language basis for the development of database applications. It
offers many advantages over C, C++, Smalltalk, BASIC, COBOL, and 4GLs for a wide variety
of uses.
Many Java application developers would like to write code that is independent of the particular
DBMS or database connectivity mechanism being used, and we believe that a DBMS-indepen-
dent interface is also the fastest way to implement access to the wide variety of DBMSs. So,
we decided it would be useful to the Java community to define a generic SQL database access
framework which provides a uniform interface on top of a variety of different database connec-
tivity modules. This allows programmers to write to a single database interface, enables
DBMS-independent Java application development tools and products, and allows database
connectivity vendors to provide a variety of different connectivity solutions.
Our immediate priority has been to define a common low-level API that supports basic SQL
functionality. We call this API JDBC. This API in turn allows the development of higher-level
database access tools and APIs.
Fortunately we didn’t need to design a SQL API from scratch. We based our work on the
X/Open SQL CLI (Call Level Interface) which is also the basis for Microsoft’s ODBC inter-
face. Our main task has been defining a natural Java interface to the basic abstractions and con-
cepts defined in the X/Open CLI.
It is important that the JDBC API be accepted by database vendors, connectivity vendors, ISVs,
and application writers. We believe that basing our work on the ODBC abstractions is likely to
make this acceptance easier, and technically ODBC seems a good basis for our design.
ODBC is not appropriate for direct use from Java, since it is a C interface; calls from Java to
native C code have a number of drawbacks in the security, implementation, robustness, and au-
tomatic portability of applications. Thus, we have constructed an API that can easily be imple-
mented on top of ODBC short-term, and that can be implemented in other ways longer term.
1.1 Acknowledgments
We would like to thank the many reviewers in the database, database connectivity, and data-
base tools communities who gave generously of their time and expertise.
We are grateful to all the reviewers who took the time to read and comment on the various
drafts, but we would particularly like to thank Azad Bolour, Paul Cotton, Ed Garon, John
Goodson, Mark Hapner, Tommy Hawkins, Karl Moss, and Barbara Walters for providing sus-
tained review and helpful feedback over many drafts and revisions of the API.
The errors and omissions that remain, are however, all our own work.
2.4 Provide a Java interface that is consistent with the rest of the Java system
There has been a very strong positive response to Java. To a large extent this seems to be be-
cause the language and the standard runtimes are perceived as being consistent, simple, and
powerful.
As far as we can, we would like to provide a Java database interface that builds on and rein-
forces the style and virtues of the existing core Java classes.
We’ve tried to adopt the same approach for the JDBC interface, and in general have preferred
to use multiple methods rather than using multi-purpose methods with flag arguments.
DriverManager
Java Application
JDBC API
JDBC Manager
JDBC Driver API
Published
protocol Proprietary database access protocols
4.1 Applets
The most publicized use of Java to date is for implementing applets that are downloaded over
the net as parts of web documents. Among these will be database access applets, and these ap-
plets could use JDBC to get to databases.
download bytecode
Java Applet Internet Web and
database access Database server(s)
JDBC Driver(s)
For example, a user might download a Java applet that displays historical price graphs for a
custom portfolio of stocks. This applet might access a relational database over the Internet to
obtain the historical stock prices.
The most common use of applets may be across untrusted boundaries, e.g. fetching applets
from another company on the Internet. Thus, this scenario might be called the “Internet” sce-
nario. However, applets might also be downloaded on a local network where client machine
security is still an issue.
Typical applets differ from traditional database applications in a number of ways:
• Untrusted applets are severely constrained in the operations they are allowed to
perform. In particular, they are not allowed any access to local files and they are not
allowed to open network connections to arbitrary hosts.
• Applets on the Internet present new problems with respect to identifying and
connecting to databases.1
• Performance considerations for a database connectivity implementation differ when the
database may be halfway around the world. Database applets on the Internet will
experience quite different network response times than database applications on a local
area network.
4.2 Applications
Java can also be used to build normal applications that run like any shrink-wrapped or custom
application on a client machine. We believe this use of Java will become increasingly common
as better tools become available for Java and as people recognize the improved programming
productivity and other advantages of Java for application development. In this case the Java
1. For example, you could not depend on your database location or driver being in a .INI file or local registry on the
client’s machine, as in ODBC.
code is trusted and is allowed to read and write files, open network connections, etc., just like
any other application code.
(possibly downloaded)
Java Application
JDBC Driver(s) database access
Perhaps the most common use of these Java applications will be within a company or on an
“Intranet,” so this might be called the Intranet scenario. For example, a company might imple-
ment all of its corporate applications in Java using GUI building tools that generate Java code
for forms based on corporate data schemas. These applications would access corporate data-
base servers on a local or wide area network. However, Java applications could also access da-
tabases through the Internet.
The Java application and “Intranet” cases differ from applets in a number of ways. For exam-
ple, the most natural way to identify a database is typically for the user or application to specify
a database name, e.g. “Customers” or “Personnel”. The users will expect the system to locate
the specific machine, DBMS, JDBC driver, and database.
Business Logic
(e.g., C++ or Java)
Application
GUI code RPC or .
(e.g., Java) CORBA .
. DBMS Servers
Additional
Desktop Client Distributed
Business Logic
Today, the middle tier is typically implemented in a language such as C or C++. With the in-
troduction of optimizing compilers translating Java byte codes into efficient machine-specific
code, the middle tier may practically be implemented in Java; Java has many valuable qualities
(robustness, security, multi-threading) for these purposes. JDBC will be of use for this middle
tier.
5 Security considerations
Based on the previous discussion, there are two main JDBC scenarios to consider for security
purposes:
• In the case of Java applications, the Java code is “trusted”. We also consider trusted
applets in this category for security purposes.
• In contrast, untrusted Java applets are not permitted access to local files and or network
connections to arbitrary hosts.
6 Database connections
For the full interface descriptions see the Java interfaces in Chapter 13.
6.3 URLs
6.3.1 Goals for JDBC database naming
We need to provide a way of naming databases so that application writers can specify which
database they wish to connect to.
1. At first glance this may seem inefficient, but keep in mind that this requires only a few procedure calls and string
comparisons per connection since it is unlikely that dozens of drivers will concurrently be loaded.
We would like this JDBC naming mechanism to have the following properties:
1. Different drivers can use different schemes for naming databases. For example, a
JDBC-ODBC bridge driver may support simple ODBC style data source names,
whereas a network protocol driver may need to know additional information so it can
discover which hostname and port to connect to.
2. If a user downloads an applet that wants to talk to a given database then we would like
to be able to open a database connection without requiring the user to do any system
administration chores. Thus for example, we want to avoid requiring an analogue of the
human-administered ODBC data source tables on the client machines. This implies that
it should be possible to encode any necessary connection information in the JDBC
name.
3. We would like to allow a level of indirection in the JDBC name, so that the initial name
may be resolved via some network naming system in order to locate the database. This
will allow system administrators to avoid specifying particular hosts as part of the
JDBC name. However, since there are a number of different network name services
(such as NIS, DCE, etc.) we do not wish to mandate that any particular network
nameserver is used.
6.3.2 URL syntax
Fortunately the World Wide Web has already standardized on a naming system that supports
all of these properties. This is the Uniform Resource Locator (URL) mechanism. So we pro-
pose to use URLs for JDBC naming, and merely recommend some conventions for structuring
JDBC URLs.
We recommend that JDBC URL’s be structured as:
jdbc:<subprotocol>:<subname>
where a subprotocol names a particular kind of database connectivity mechanism that may be
supported by one or more drivers. The contents and syntax of the subname will depend on the
subprotocol.
If you are specifying a network address as part of your subname, we recommend following the
standard URL naming convention of “//hostname:port/subsubname” for the subname. The sub-
subname can have arbitrary internal syntax.
6.3.3 Example URLs
For example, in order to access a database through a JDBC-ODBC bridge, one might use a
URL like:
jdbc:odbc:fred
In this example the subprotocol is “odbc” and the subname is a local ODBC data source name
“fred”. A JDBC-ODBC driver can check for URLs that have subprotocol “odbc” and then use
the subname in an ODBC SQLConnect.
If you are using some generic database connectivity protocol “dbnet” to talk to a database lis-
tener, you might have a URL like:
jdbc:dbnet://wombat:356/fred
In this example the URL specifies that we should use the “dbnet” protocol to connect to port
356 on host wombat and then present the subsubname “fred” to that port to locate the final da-
tabase.
If you wish to use some network name service to provide a level of indirection in database
names, then we recommend using the name of the naming service as the subprotocol. So for
example one might have a URL like:
jdbc:dcenaming:accounts-payable
In this example, the URL specifies that we should use the local DCE naming service to resolve
the database name “accounts-payable” into a more specific name that can be used to connect
to the real database. In some situations, it might be appropriate to provide a pseudo driver that
performed a name lookup via a network name server and then used the resulting information
to locate the real driver and do the real connection open.
6.3.4 Drivers can choose a syntax and ignore other URLs.
In summary, the JDBC URL mechanism is intended to provide a framework so that different
drivers can use different naming systems that are appropriate to their needs. Each driver need
only understand a single URL naming syntax, and can happily reject any other URLs that it
encounters.
6.3.5 Registering subprotocol names
JavaSoft will act as an informal registry for JDBC sub-protocol names. Send mail to jd-
[email protected] to reserve a sub-protocol name.
6.3.6 The “odbc” subprotocol
The “odbc” subprotocol has been reserved for URLs that specify ODBC style Data Source
Names. For this subprotocol we specify a URL syntax that allows arbitrary attribute values to
be specified after the data source name.
The full odbc subprotocol URL syntax is:
jdbc:odbc:<data-source-name>[;<attribute-name>=<attribute-value>]*
Thus valid jdbc:odbc names include:
jdbc:odbc:qeor7
jdbc:odbc:wombat
jdbc:odbc:wombat;CacheSize=20;ExtensionCase=LOWER
jdbc:odbc:qeora;UID=kgh;PWD=fooey
In order to allow applets to access databases in a generic way, we recommend that as much con-
nection information as possible be encoded as part of the URL and that driver writers minimize
their use of property sets.
In both cases it is the responsibility of each newly loaded Driver class to register itself with the
DriverManager, using the DriverManager.registerDriver method. This will allow the Driver-
Manager to use the driver when it is attempting to make database connections.
For security reasons the JDBC management layer will keep track of which class loader provid-
ed which driver and when opening connections it will only use drivers that come from the local
filesystem or from the same classloader as the code issuing the getConnection request.
T S I B R F D D N B C V L B V L D T T
Y M N I E L O E U I H A O I A O A I I
I A T G A O U C M T A R N N R N T M M
N L E I L A B I E R C G A B G E E E
Y L G N T L M R H V R I V S
I I E T E A I A A Y N A T
N N R L C R R A R A
T T C R B M
H Y I P
A N
R A
R
Y
getByte X x x x x x x x x x x x x
getShort x X x x x x x x x x x x x
getInt x x X x x x x x x x x x x
getLong x x x X x x x x x x x x x
getFloat x x x x X x x x x x x x x
getDouble x x x x x X X x x x x x x
getBigDecimal x x x x x x x X X x x x x
getBoolean x x x x x x x x x X x x x
getString x x x x x x x x x x X X x x x x x x x
getBytes X X x
getDate x x x X x
getTime x x x X x
getTimestamp x x x x X
getAsciiStream x x X x x x
getUnicodeStream x x X x x x
getBinaryStream x x X
getObject x x x x x x x x x x x x x x x x x x x
However under some circumstances an application may not know whether a given statement
will return a ResultSet until the statement has executed. In addition, some stored procedures
may return several different ResultSets and/or update counts.
To accommodate these needs we provide a mechanism so that an application can execute a
statement and then process an arbitrary collection of ResultSets and update counts. This mech-
anism is based on a fully general “execute” method, supported by three other methods, getRe-
sultSet, getUpdateCount, and getMoreResults. These methods allow an application to explore
the statement results one at a time and to determine if a given result was a ResultSet or an up-
date count.
Similarly table 3 shows the reverse mapping from Java types to SQL types.
String is sent to a CHAR(n) field, the driver and/or the database will add any necessary padding
spaces to the end of the String to bring it up to length “n”.
The ResultSet.getString method allocates and returns a new String. This is suitable for retriev-
ing normal data, but the LONGVARCHAR SQL type can be used to store multi-megabyte
strings. We therefore needed to provide a way for Java programmers to retrieve a LONGVAR-
CHAR value in chunks. We handle this by allowing programmers to retrieve a LONGVAR-
CHAR as a Java input stream from which they can subsequently read data in whatever chunks
they prefer. Java streams can be used for either Unicode or Ascii data, so the programmer may
chose to use either getAsciiStream or getUnicodeStream.
8.6 BIT
The SQL BIT type can be mapped directly to the Java boolean type.
9.2 Multi-threading
We require that all operations on all the java.sql objects be multi-thread safe and able to cope
correctly with having several threads simultaneously calling the same object.
Some drivers may allow more concurrent execution than others. Developers can assume fully
concurrent execution; if the driver requires some form of synchronization, it will provide it.
The only difference visible to the developer will be that applications will run with reduced con-
currency.
For example, two Statements on the same Connection can be executed concurrently and their
ResultSets can be processed concurrently (from the perspective of the developer). Some drivers
will provide this full concurrency. Others may execute one statement and wait until it com-
pletes before sending the next.
One specific use of multi-threading is to cancel a long running statement. This is done by using
one thread to execute the statement and another to cancel it with its Statement.cancel() method.
In practice we expect that most of the JDBC objects will only be accessed in a single threaded
way. However some multi-thread support is necessary, and our attempts in previous drafts to
specify some classes as MT safe and some as MT unsafe appeared to be adding more confusion
than light.
9.3 Transactions.
New JDBC connections are initially in “auto-commit” mode. This means that each statement
is executed as a separate transaction at the database.
In order to execute several statements within a single transaction, you must first disable auto-
commit by calling Connection.setAutoCommit(false).
When auto-commit is disabled, the connection always has an implicit transaction associated
with it. You can execute a Connection.commit to complete the transaction or a Connection.roll-
back to abort it. The commit or rollback will also start a new implicit transaction.
The exact semantics of transactions and their isolation levels depend on the underlying data-
base. There are methods on java.sql.DatabaseMetaData to learn the current defaults, and on ja-
va.sql.Connection to move a newly opened connection to a different isolation level.
In the first version of the interface we will provide no support for committing transactions across
different connections.
10 Cursors
JDBC provides simple cursor support. An application can use ResultSet.getCursorName() to
obtain a cursor associated with the current ResultSet. It can then use this cursor name in posi-
tioned update or positioned delete statements.
The cursor will remain valid until the ResultSet or its parent Statement is closed.
Note that not all DBMSs support positioned update and delete. The DatabaseMetaData.sup-
portsPositionedDelete and supportsPositionedUpdate methods can be used to discover whether
a particular connection supports these operations. When they are supported, the DBMS/driver
must insure that rows selected are properly locked so that positioned updates do not result in
update anomalies or other concurrency problems.
Currently we do not propose to provide support for either scrollable cursors or ODBC style
bookmarks as part of JDBC.
11 SQL Extensions
Certain SQL features beyond SQL-2 Entry Level are widely supported and are desirable to in-
clude as part of our JDBC compliance definition so that applications can depend on the porta-
bility of these features. However, SQL-2 Transitional Level, the next higher level of SQL
compliance defined by ANSI, is not widely supported. Where Transitional Level semantics are
supported, the syntax is often different across DBMSs.
We therefore define two kinds of extensions to SQL-2 Entry Level that must be supported by
a JDBC-Compliant driver:
• Selective Transitional Level syntax and semantics must be supported. We currently
demand just one such feature: the DROP TABLE command is required for JDBC
compliance.
• Selective Transitional Level semantics must be supported through an escape syntax that
a driver can easily scan for and translate into DBMS-specific syntax. We discuss these
escapes in the remainder of Section 11. Note that these escapes need only be supported
where the underyling database supports the corresponding Transitional Level
semantics.
An ODBC driver that supports ODBC Core SQL as defined by Microsoft complies with JDBC
SQL as defined in this section.
This ODBC-compatible escape syntax is in general not the same as has been adopted by ANSI
in SQL-2 Transitional Level for the same functionality. In cases where all of the desired
DBMSs support the standard SQL-2 syntax, the user is encouraged to use that syntax instead
of these escapes. When enough DBMSs support the more advanced SQL-2 syntax and seman-
tics these escapes should no longer be necessary.
Input arguments may be either literals or parameters. To determine if stored procedures are
supported, call DatabaseMetaData.supportsStoredProcedure.
where yyyy-mm-dd provides the year, month, and date, e.g. 1996-02-28. The driver will re-
place this escape clause with the equivalent DBMS-specific representation, e.g. ‘Feb 28, 1996’
for Oracle.
There are analogous escape clauses for TIME and TIMESTAMP:
{t ‘hh:mm:ss’}
The name of the current user can be obtained through the syntax
{fn user()}
See the X/Open CLI or ODBC specifications for specifications of the semantics of the scalar
functions. The functions supported are listed here for reference. Some drivers may not support
all of these functions; to find out which functions are supported, use the folowing Data-
baseMetadata methods: getNumericFunctions() returns a comma separated list of the names of
the numeric functions supported, getStringFunctions() does the same for the string functions,
and so on.
The numeric functions are ABS(number), ACOS(float), ASIN(float), ATAN(float),
ATAN2(float1, float2), CEILING(number), COS(float), COT(float), DEGREES(number),
EXP(float), FLOOR(number), LOG(float), LOG10(float), MOD(integer1, integer2), PI(),
See the SQL grammar for an explanation of outer joins. Three boolean DatabaseMetaData
methods are provided to determine the kinds of outer joins supported by a driver.
The JDBC API documentation also includes definitions of the JDBC metadata interfaces - ja-
va.sql.DatabaseMetaData and java.sql.ResultSetMetaData. See also the short example programs in
Appendix B.
The more important relationships between the interfaces are as follows (with arrows showing func-
tions and lines showing other methods):
executeQuery
crea commit, abort
ResultSet getMoreResults Statement teSt
atem
ent
exe subclass
cut execute nt Connection
eQ Stateme
uer
y prepare
getXXX
all
PreparedStatement getConnection
areC
prep
subclass
X
X
DriverManager
tX
se
The corresponding default mapping from Java Object types to SQL types is show in Table 5.
Note that it is not possible to send or receive Java input streams using the getObject or setOb-
ject methods. You must explicitly use PreparedStatement.setXXXStream or Result-
Set.getXXXStream to transfer a value as a stream.
14.2.1 ResultSet.getObject
ResultSet.getObject returns a Java object whose type correspond to the SQL type of the Result-
Set column, using the mapping specified in Table 4.
So for example, if you have a ResultSet where the “a” column has SQL type CHAR, and the
“b” column has SQL type SMALLINT, here are the types returned by some getObject calls:
ResultSet rs = stmt.executeQuery(“SELECT a, b FROM foo”);
while (rs.next()) {
Object x = rs.getObject(“a”); // gets a String
Object y = rs.getObject(“b”); // gets an Integer
}
14.2.2 PreparedStatement.setObject
For PreparedStatement.setObject you can optionally specify a target SQL type. In this case the
argument Java Object will first be mapped to its default SQL type (as specified in Table 5),
then converted to the specified SQL type (see Table 6), and then sent to the database.
Alternatively you can omit the target SQL type, in which case the given Java Object will simply
get mapped to its default SQL type (using Table 5) and then be sent to the database .
14.2.3 CallableStatement.getObject
Before calling CallableStatement.getObject you must first have specified the parameter’s SQL
type using CallableStatement.registerOutParameter. When you call CallableStatement.getOb-
ject the Driver will return a Java Object type corresponding to that SQL type, using the map-
ping specified Table 4.
T S I B R F D D N B C V L B V L D T T
Y M N I E L O E U I H A O I A O A I I
I A T G A O U C M T A R N N R N T M M
N L E I L A B I E R C G A B G E E E
Y L G N T L M R H V R I V S
I I E T E A I A A Y N A T
N N R L C R R A R A
T T C R B M
H Y I P
A N
R A
R
Y
String x x x x x x x x x x x x x x x x x x x
java.math.BigDecimal x x x x x x x x x x x x x
Boolean x x x x x x x x x x x x x
Integer x x x x x x x x x x x x x
Long x x x x x x x x x x x x x
Float x x x x x x x x x x x x x
Double x x x x x x x x x x x x x
byte[] x x x
java.sql.Date x x x x x
java.sql.Time x x x x
java.sql.Timestamp x x x x x x
Table 6: Conversions performed by setObject between Java object types and target SQL types.
An “x” means that the given Java object type may be converted to the given SQL type.
Note that some conversions may fail at runtime if the value presented is invalid.
A.2 Design Alternative: Don’t use types such as fooHolder, instead use foo[]
At some point in the future we would probably like to add support for some form of column-wise
binding, so that a bunch of rows can be read at once. When we were using the Holder design,
we considered the following design alternative that would allow for column-wise binding.
Holder objects are capable of holding single instances of various Java types. However an array
of a single element could instead be used as a holder. This approach has several disadvantages,
but one major advantage.
The first disadvantage is that people may be confused if they read “foo f[] = new foo[1];”. The
corresponding holder declaration “fooHolder f = new fooHolder();” gives a better clue as to
what f is and why we are allocating it.
The second disadvantage is that we would have to replace the single method Statement.bind-
Column with a distinct method for each array type. This is because all our Holder types inherit
from java.sql.Holder and can therefore be passed as arguments to a generic method that takes
a java.sql.Holder argument. (On the other hand at least we avoid defining the dozen or so hold-
er classes.)
The last disadvantage is that using foo[] only gives us the raw Java type information. By defin-
ing a specific set of holder types for use with SQL, we can define extra fields and/or semantics,
e.g. for the CurrencyHolder type.
The corresponding major advantage is that if we use foo[1] as the container for a parameter
then it is very natural to allow foo[x] as a way of binding multiple rows of a table in column-
wise binding. This would let us add support for column-wise binding without having to remod-
el the interface.
If we use arrays instead of Holders, them the bindColumn mechanism makes it easier to scale
up to column-wise binding.
Unfortunately, harsh reality intervened and it emerged that “isNull” could not be implemented
reliably on all databases. Some databases have no separate means for determining if a column
is null other than reading the column and they would only permit a given column to be read
once. We looked at reading the column value and “remembering” it for later use, but this
caused problems when data conversions were required.
After examining a number of different solutions we reluctantly decided to replace the isNull
method with the wasNull method. The wasNull method merely reports whether the last value
read from the given ResultSet (or CallableStatement) was SQL NULL.
class Select {
stmt.close();
con.close();
} catch (java.lang.Exception ex) {
ex.printStackTrace();
}
}
}
import java.net.URL;
import java.sql.*;
class Update {
stmt.close();
con.close();
Changes between 1.00 and 1.01 - all of the changes are clarificationsand errata; no actual
changes to the specification have been made. Most of the clarifications only affect the API doc-
umentation.
• Removed getBinary for CHAR types from ResultSet conversion table. These were
simply in error.
• Noted that the precision used for setXXX and setObject is a maximum precision value
chosen by the driver.
• The description of the various SQL identifier case sensitivity and case storage modes
were clarified and the JDBC driver requirements were adjusted.
• Added a note that JDBC java.io.stream.available() may return 0 whether or note data is
available. JDBC drivers may not be able to provide an accurate count of available data.
• Statement.getMoreResults termination conditions were not documented correctly. This
was corrected.
• Noted that Statement.executeUpdate implicitly closes the statement's current result set.
• The Driver comments were changed to note that a static section should create an
instance and register it. This was a documentation error.
• Fixed parameters for getCrossReference. They were documented in error.
• Noted that a SQLException should be thrown if the driver does not support a
DatabaseMetaData method.
• Noted that executeQuery never returns a null ResultSet ref
• Clarified the semantics of auto commit for the case of statements that return results.
• Removed ColumnName from the getTablePrivileges ResultSet; this was added in error.
• Noted that CallableStatement ResultSets and update counts should be processed prior
to getting output parameter values.
The following changes have been made to JDBC 1.10. All of these changes are minor clarifi-
cations or additions. Unfortunately, although the removal of auto close and the java.sql.Numer-
ic name change are minor they are not backward compatible. In particular, the name change
requires that drivers must be updated to work with JDBC 1.1.
• Revised isolation level description
• Revised getTablePrivileges description to note that a privilege applies to one or more
columns of the table.
• Revised preserve across commit/rollback metadata to specify positive case while
allowing negative case result in partial preservation.
• Added NO ACTION and SET DEFAULT values for getImportedKeys,
getExportedKeys and getCrossReference ON DELETE and ON UPDATE
• Added DEFERRABILITY attribute to getImportedKeys, getExportedKeys and
getCrossReference
• Removed the auto close facility
• Rename java.sql.Numeric to java.lang.Bignum
• Note that for maximum portability values less than 256 should not be used for
setMaxFieldSize
• Changed initialization of SQLState to null from "" to agree with initialization of reason.
• Clarify definition of Date, Time and Timestamp
• Added private constructor to DriverManager and Types to prevent instantiation.
• Added millis constructor for Date, Time and Timestamp