Tables 16-6 and 16-7 show the mapping between the getXXX methods and JDBC SQL types of ResultSet and CallableStatement.

If a getXXX method is called for an unsupported JDBC SQL type, the JDBC driver throws an SQLException. For details about the JDBC SQL types supported by the connected database, see 16.12 Data types and character codes.

Note that the getCharacterStream method has been added because the getUnicodeStream method is no longer recommended in the JDBC2.0 basic standard.

Table 16-6 Mapping between the getXXX methods and JDBC SQL types of ResultSet and CallableStatement (1/2)

getXXX method	JDBC SQL type
	SMALLINT	INTEGER	FLOAT	REAL	DECIMAL	CHAR
getByte	M	M	M	M	M	M2
getShort	R	M	M	M	M	M2
getInt	M	R	M	M	M	M2
getLong	M	M	M	M	M	M2
getFloat	M	M	M	R	M	M2
getDouble	M	M	R	M	M	M2
getBigDecimal	M	M	M	M	R	M2
getBoolean	M	M	M	M	M	M
getString	M	M	M	M	M	R
getBytes
getDate						M2
getTime						M2
getTimestamp						M2
getAsciiStream						M
getUnicodeStream						M
getBinaryStream
getObject	M	M	M	M	M	M
getCharacterStream						M
getArray
getBlob
getClob1
getRef1

Legend:

R: Mapping is recommended.

M: Can be mapped.

: Cannot be mapped.

¹ Not supported by the JDBC driver.

² When the data from the character string is converted, any single-byte spaces that precede or follow the character string data acquired from the database are stripped, before the data is converted to the Java data type that is to be returned by the getXXX method.

Note the following when you convert data to a Java data type:

• If there is an expression following the decimal point in text string data and the getByte, getInt, getShort, or getLong method is executed, the data following the decimal point is truncated and only the integer digits are converted and returned.
• If character string data contains double-byte characters, the method throws an SQLException. Double-byte characters include double-byte spaces filled when a character string shorter than the definition length of a column is stored in an NCHAR column.
• If overflow occurs when character string data is converted to the Java data type, the method throws an SQLException.
• If the execution environment of the UAP is JDK or JRE 1.2 and the character string data uses exponential notation (such as 1.23E-23) and the getLong method or getBigDecimal method is executed, the method throws an SQLException.
  

  Table 16-7 Mapping between the getXXX methods and JDBC SQL types of ResultSet and CallableStatement (2/2)

  getXXX method	JDBC SQL type
  	VARCHAR	DATE	TIME	TIMESTAMP	LONGVARBINARY	ARRAY
  getByte	M2
  getShort	M2
  getInt	M2
  getLong	M2
  getFloat	M2
  getDouble	M2
  getBigDecimal	M2
  getBoolean	M2
  getString	R	M	M	M	M
  getBytes					M
  getDate	M2	R3		M
  getTime	M2		R	M
  getTimestamp	M2	M		R
  getAsciiStream	M				M
  getUnicodeStream	M				M
  getBinaryStream					R
  getObject	M	M	M	M	M	M
  getCharacterStream	M				M
  getArray						R
  getBlob					M
  getClob1
  getRef1

Legend:

R: Mapping is recommended.

M: Can be mapped.

: Cannot be mapped.

¹ Not supported by the JDBC driver.

² In data conversion from character string data, any single-byte spaces that exist before and after the character string data is acquired from the database are removed, and then the data is converted to the Java data type returned by the getXXX method.

Note the following when you convert data to a Java data type:

• If there is an expression following the decimal point in text string data and the getByte, getInt, getShort, or getLong method is executed, the data following the decimal point is truncated and only the integer digits are converted and returned.
• If character string data contains double-byte characters, the method throws an SQLException. Double-byte characters include double-byte spaces filled when a character string shorter than the definition length of a column is stored in an NCHAR column.
• If overflow occurs when character string data is converted to the Java data type, the method throws an SQLException.
• If the execution environment of the UAP is JDK or JRE 1.2 and the character string data uses exponential notation (such as 1.23E-23) and the getLong method or getBigDecimal method is executed, the method throws an SQLException.

³ When the JDBC SQL type is the DATA type and conversion is executed by specifying a java.util.Calendar object for the setDate method, the specified java.util.Calendar object is used for data conversion, time data is truncated, and only date data is stored in the database. In such a case, even if you specify the java.util.Calendar object for the getDate method to acquire the data stored using the setDate method, a different date than the date specified for the setDate method may be acquired.

Example:

The following is an example of when a java.util.Calendar object using Universal Time (UTC) is specified for the setDate and getDate methods in a UAP that uses Japanese standard time as the default time zone.

When you specify a java.sql.Date object that represents 2005-10-03 for the setDate method and then execute it, the JDBC driver adds 00:00:00 in the time part, and then stores the date part as 2005-10-02 in the database by delaying 9 hours because of the time zone difference. If this data is acquired using the getDate method, the date part 2005-10-02 is acquired from the database and 00:00:00 is added for the time part, and then 2005-10-02 09:00:00 is set by advancing 9 hours because of the time zone difference. Because of this, 2005-10-02 is set in the java.sql.Date object return value of the getDate method, which is different from the 2005-10-03 date specified for the setDate method.

Table 16-8 shows setXXX methods and JDBC SQL types to be mapped for the PreparedStatement class and CallableStatement. For an unsupported JDBC SQL type, the setXXX method throws an SQLException. For details about the JDBC SQL types supported by the connected database, see 16.12 Data types and character codes.

Note that the setCharacterStream method has been added because the setUnicodeStream method is no longer recommended in the JDBC2.0 basic standard.

Table 16-8 setXXX methods and JDBC SQL types to be mapped for PreparedStatement class

PreparedStatement class's setXXX method	JDBC SQL type to be mapped
setCharacterStream	CHAR, VARCHAR, or LONGVARCHAR
SetRef*	REF
setBlob	LONGVARBINARY
setClob*	CLOB
setArray	ARRAY

^* Not supported by the JDBC driver.

Tables 16-9 and 16-10 show the mapping between the setXXX methods and JDBC SQL types of PreparedStatement and CallableStatement.

Table 16-9 Mapping between the setXXX methods and JDBC SQL types of PreparedStatement and CallableStatement (1/2)

setXXX method	JDBC SQL type
	SMALLINT	INTEGER	FLOAT	REAL	DECIMAL	CHAR
setByte	M	M	M	M	M	M
setShort	R	M	M	M	M	M
setInt	M	R	M	M	M	M
setLong	M	M	M	M	M	M
setFloat	M	M	M	R	M	M
setDouble	M	M	R	M	M	M
setBigDecimal	M	M	M	M	R	M
setBoolean	M	M	M	M	M	M
setString	M	M	M	M	M	R
setBytes
setDate						M
setTime						M
setTimestamp						M
setAsciiStream						M
setUnicodeStream						M
setBinaryStream
setObject	M	M	M	M	M	M
setCharacterStream						M
setArray
setBlob
setClob*
setRef*

Legend:

R: Mapping is recommended.

M: Can be mapped. Note that data may be missing or a conversion error may occur depending on the format of source data.

: Cannot be mapped.

^* Not supported by the JDBC driver.

Table 16-10 Mapping between the setXXX methods and JDBC SQL types of PreparedStatement and CallableStatement (2/2)

setXXX method	JDBC SQL type
	VARCHAR	DATE	TIME	TIMESTAMP	LONGVARBINARY	ARRAY
setByte	M
setShort	M
setInt	M
setLong	M
setFloat	M
setDouble	M
setBigDecimal	M
setBoolean	M
setString	R	M	M	M	M
setBytes					M
setDate	M	R2		M
setTime	M		R	M
setTimestamp	M	M		R
setAsciiStream	M				M
setUnicodeStream	M				M
setBinaryStream					R
setObject	M	M	M	M	M	M
setCharacterStream	M				M
setArray						R
setBlob					M
setClob1
setRef1

Legend:

R: Mapping is recommended.

M: Can be mapped. Note that data may be missing or a conversion error may occur depending on the format of source data.

: Cannot be mapped.

¹ Not supported by the JDBC driver.

² When the JDBC SQL type is the DATA type and conversion is executed by specifying a java.util.Calendar object for the setDate method, the specified java.util.Calendar object is used for data conversion, time data is truncated, and only date data is stored in the database. In such a case, even if you specify the java.util.Calendar object for the getDate method to acquire the data stored using the setDate method, a different date than the date specified for the setDate method may be acquired.

Example:

The following is an example of what happens when a java.util.Calendar object using Universal Time (UTC) is specified for the setDate and getDate methods in a UAP that uses Japanese standard time as the default time zone.

When you specify a java.sql.Date object that represents 2005-10-03 for the setDate method, and then execute it, the JDBC driver adds 00:00:00 in the time part and then stores the date part as 2005-10-02 in the database by delaying 9 hours because of the time zone difference. If this data is acquired using the getDate method, the date part 2005-10-02 is acquired from the database and 00:00:00 is added for the time part, and then 2005-10-02 09:00:00 is set by advancing 9 hours because of the time zone difference. Because of this, 2005-10-02 is set in the java.sql.Date object return value of the getDate method, which is different from the 2005-10-03 date specified for the setDate method.