|Contents | Prev | Next||JDBCTM Guide: Getting Started|
ResultSet.getBigDecimal()method that returns full precision has been added.
ResultSetMetaData.getColumnType()method may now return the new SQL type codes:
BLOB, etc. The
DISTINCTtype codes are always returned for structured and distinct values, independent of whether the default or a custom type mapping is being used.
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|
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
ResultSetMetaData.getColumnTypeName() method returns a fully qualified
SQL type name when the type code is STRUCT, DISTINCT, or JAVA_OBJECT.
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.
DatabasemetaData.getConnection() to return the
that produced the metadata object.
DatabasemetaData.getUDTs(). See the separate API documentation
Added methods to support the new
ResultSet and batch update functionality:
supportsBatchUpdates(), etc. See the separate
API documentation for details.
DriverManager.setLogWriter()method that takes a
java.io.PrintWriterobject as input has been added. A new
DriverManager.getLogWriter()method returns a
set/getLogStream()methods have been deprecated.
Timestampvalues for a particular time zone using a
Calendar. For example,
returns aResultSet rs; ... Date date1 = rs.getDate(1);
Dateobject 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
Calendarwas 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
Calendar explicitly since the JDBC driver will use the default time zone by
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
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
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.