JDK 5 Documentation v1.2.2, Java 2 SDK 英文文档

JDBC^TM Guide: Getting Started

10 Other New Features

This chapter describes additional changes that have been made in the JDBC 2.0 API.

10.1 Changes to java.sql.ResultSet

A version of the ResultSet.getBigDecimal() method that returns full precision has been added.

10.2 Changes to java.sql.ResultSetMetaData

The ResultSetMetaData.getColumnType() method may now return the new SQL type codes: STRUCT, DISTINCT, BLOB, etc. The STRUCT and DISTINCT type codes are always returned for structured and distinct values, independent of whether the default or a custom type mapping is being used.

The ResultSetMetaData.getColumnTypeName() method should return the following for the new SQL types.

Column Type Column Type Name
JAVA_OBJECT the SQL name of the Java type
DISTINCT the SQL name of the distinct type
STRUCT the SQL name of the structured type
ARRAY data source dependent type name
BLOB data source dependent type name
CLOB data source dependent type name
REF data source dependent type name

Column Type	Column Type Name
JAVA_OBJECT	the SQL name of the Java type
DISTINCT	the SQL name of the distinct type
STRUCT	the SQL name of the structured type
ARRAY	data source dependent type name
BLOB	data source dependent type name
CLOB	data source dependent type name
REF	data source dependent type name

A ResultSetMetaData.getColumnClassName() method has been added to return the fully qualified name of the Java class whose instances are manufactured if ResultSet.getObject() is called to retrieve a value from the column. See the separate API documentation for details.

The ResultSetMetaData.getColumnTypeName() method returns a fully qualified SQL type name when the type code is STRUCT, DISTINCT, or JAVA_OBJECT.

10.3 Changes to DatabaseMetaData

The DatabaseMetaData.getColumns() method may now return DATA_TYPE values of the new SQL3 types: BLOB, CLOB, etc. The

DatabaseMetaData.getColumns()

method returns the same type names as those listed in Section 10.2 for the SQL3 data types.

Added method DatabasemetaData.getConnection() to return the Connection object that produced the metadata object.

Added method DatabasemetaData.getUDTs(). See the separate API documentation for details.

Added methods to support the new ResultSet and batch update functionality: supportsResultSetConcurrency(), supportsBatchUpdates(), etc. See the separate API documentation for details.

10.4 Changes to java.sql.DriverManager

A DriverManager.setLogWriter() method that takes a java.io.PrintWriter object as input has been added. A new DriverManager.getLogWriter() method returns a PrintWriter object. The set/getLogStream() methods have been deprecated.

10.5 Date, Time, and Timestamp

The JDBC API follows the Java platform's approach of representing dates and times as a millisecond value relative to January 1, 1970 00:00:00 GMT. Since most databases don't support the notion of a time zone, the JDBC 2.0 API adds new methods to allow a JDBC driver to get/set Date, Time, and Timestamp values for a particular time zone using a Calendar. For example,

ResultSet rs;
...
Date date1 = rs.getDate(1);

returns a Date object that wraps a millisecond value which denotes a particular date, like January 3, 1999, and a normalized time 00:00:00 in the default time zone. The time component of the Date is set to zero in the default time zone since SQL DATE values don't have a time component. Since a Calendar was not supplied explicitly to

getDate()

, the default time zone (really the default Calendar) is used by the JDBC driver internally to create the appropriate millisecond value assuming that the underlying database doesn't store time zone information.

The following example retrieves a date value in GMT-Greenwich Mean Time.

ResultSet rs;
...

TimeZone.setDefault(TimeZone.getTimeZone("GMT"));
Calendar cal = Calendar.getInstance();
Date date2 = rs.getDate(1, cal);

In the example above, a Calendar is passed explicitly to getDate() to inform the JDBC driver how to calculate the appropriate millisecond value. Note that the same result could have been achieved by simply changing the default time zone, and not passing the Calendar explicitly since the JDBC driver will use the default time zone by default.

Note that the two Date objects created above will not compare as equal assuming that the default time zone is not GMT, even if they represent the `same' date.

if (date1.equals(date2))
	//never get here

This is because each Java language Date object really just wraps a normalized millisecond time value and these millisecond values will differ across time zones. If an application wishes to compare dates in different time zones it should first convert them to a Calendar.

An application should create a Date object using a Calendar. The application is responsible for specifying the time as 00:00:00 on the desired date when using the Calendar since JDBC uses this convention. In addition when creating a Time value the application must specify a date of January 1, 1970 to the Calendar used to create the millisecond value for the Time as this is the convention specified by JDBC for time.

Contents | Prev | Next

jdbc@eng.sun.com or jdbc-business@eng.sun.com