org.hsqldb.jdbc
public class jdbcPreparedStatement extends jdbcStatement implements PreparedStatement
An SQL statement is precompiled and stored in a
PreparedStatement
object. This object can then be used to
efficiently execute this statement multiple times.
Note: The setter methods (setShort
,
setString
, and so on) for setting IN parameter values
must specify types that are compatible with the defined SQL type of
the input parameter. For instance, if the IN parameter has SQL type
INTEGER
, then the method setInt
should be
used.
If arbitrary parameter type conversions are required, the method
setObject
should be used with a target SQL type.
In the following example of setting a parameter, con
represents an active connection:
PreparedStatement pstmt = con.prepareStatement("UPDATE EMPLOYEES SET SALARY = ? WHERE ID = ?"); pstmt.setBigDecimal(1, 153833.00) pstmt.setInt(2, 110592)
Starting with HSQLDB 1.7.2, jdbcPreparedStatement objects are backed by a true compiled parameteric representation. Hence, there are now significant performance gains to be had by using a jdbcPreparedStatement object in preference to a jdbcStatement object, if a short-running SQL statement is to be executed more than a small number of times.
When it can be otherwise avoided, it is to be considered poor practice to fully prepare (construct), parameterize, execute, fetch and close a jdbcPreparedStatement object for each execution cycle. Indeed, under HSQLDB 1.8.0, this practice is likely to be noticably less performant for short-running statements than the equivalent process using jdbcStatement objects, albeit far more convenient, less error prone and certainly much less resource-intensive, especially when large binary and character values are involved, due to the optimized parameterization facility.
Instead, when developing an application that is not totally oriented toward the execution of ad hoc SQL, it is recommended to expend some effort toward identifing the SQL statements that are good candidates for regular reuse and adapting the structure of the application accordingly. Often, this is done by recording the text of candidate SQL statements in an application resource object (which has the nice side-benefit of isolating and hiding differences in SQL dialects across different drivers) and caching for possible reuse the PreparedStatement objects derived from the recorded text.
Multi thread use:
A PreparedStatement object is stateful and should not normally be shared by multiple threads. If it has to be shared, the calls to set the parameters, calls to add batch statements, the execute call and any post-execute calls should be made within a block synchronized on the PreparedStatement Object.
JRE 1.1.x Notes:
In general, JDBC 2 support requires Java 1.2 and above, and JDBC3 requires Java 1.4 and above. In HSQLDB, support for methods introduced in different versions of JDBC depends on the JDK version used for compiling and building HSQLDB.
Since 1.7.0, it is possible to build the product so that
all JDBC 2 methods can be called while executing under the version 1.1.x
Java Runtime EnvironmentTM.
However, in addition to requiring explicit casts to the org.hsqldb.jdbcXXX
interface implementations, some of these method calls require
int
values that are defined only in the JDBC 2 or greater
version of
ResultSet
interface. For this reason, when the
product is compiled under JDK 1.1.x, these values are defined in
{@link jdbcResultSet jdbcResultSet}.
In a JRE 1.1.x environment, calling JDBC 2 methods that take or return the
JDBC2-only ResultSet
values can be achieved by referring
to them in parameter specifications and return value comparisons,
respectively, as follows:
jdbcResultSet.FETCH_FORWARD jdbcResultSet.TYPE_FORWARD_ONLY jdbcResultSet.TYPE_SCROLL_INSENSITIVE jdbcResultSet.CONCUR_READ_ONLY // etc.However, please note that code written in such a manner will not be compatible for use with other JDBC 2 drivers, since they expect and use
ResultSet
, rather than jdbcResultSet
. Also
note, this feature is offered solely as a convenience to developers
who must work under JDK 1.1.x due to operating constraints, yet wish to
use some of the more advanced features available under the JDBC 2
specification.
(fredt@users)
(boucherb@users)
See Also: jdbcConnection jdbcResultSet
Method Summary | |
---|---|
void | addBatch() |
void | addBatch(String sql)
This method should always throw if called for a PreparedStatement or
CallableStatment.
|
void | clearParameters() |
void | close()
Does the specialized work required to free this object's resources and
that of it's parent class. |
boolean | execute() |
boolean | execute(String sql)
This method should always throw if called for a PreparedStatement or
CallableStatment.
|
int[] | executeBatch() |
ResultSet | executeQuery() |
ResultSet | executeQuery(String sql)
This method should always throw if called for a PreparedStatement or
CallableStatment.
|
int | executeUpdate() |
int | executeUpdate(String sql)
This method should always throw if called for a PreparedStatement or
CallableStatment.
|
ResultSetMetaData | getMetaData() |
ParameterMetaData | getParameterMetaData() |
void | setArray(int i, Array x) |
void | setAsciiStream(int parameterIndex, InputStream x, int length) |
void | setBigDecimal(int parameterIndex, BigDecimal x) |
void | setBinaryStream(int parameterIndex, InputStream x, int length) |
void | setBlob(int i, Blob x) |
void | setBoolean(int parameterIndex, boolean x) |
void | setByte(int parameterIndex, byte x) |
void | setBytes(int paramIndex, byte[] x) |
void | setCharacterStream(int parameterIndex, Reader reader, int length) |
void | setClob(int i, Clob x) |
void | setDate(int parameterIndex, Date x) |
void | setDate(int parameterIndex, Date x, Calendar cal) |
void | setDouble(int parameterIndex, double x) |
void | setEscapeProcessing(boolean enable) |
void | setFloat(int parameterIndex, float x) |
void | setInt(int parameterIndex, int x) |
void | setLong(int parameterIndex, long x) |
void | setNull(int paramIndex, int sqlType) |
void | setNull(int paramIndex, int sqlType, String typeName) |
void | setObject(int parameterIndex, Object x, int targetSqlType, int scale) |
void | setObject(int parameterIndex, Object x, int targetSqlType) |
void | setObject(int parameterIndex, Object x) |
void | setRef(int i, Ref x) |
void | setShort(int parameterIndex, short x) |
void | setString(int parameterIndex, String x) |
void | setTime(int parameterIndex, Time x) |
void | setTime(int parameterIndex, Time x, Calendar cal) |
void | setTimestamp(int parameterIndex, Timestamp x) |
void | setTimestamp(int parameterIndex, Timestamp x, Calendar cal) |
void | setUnicodeStream(int parameterIndex, InputStream x, int length) |
void | setURL(int parameterIndex, URL x) |
String | toString()
Retrieves a String representation of this object. |
PreparedStatement
object's batch of commands.
Since 1.7.2, this feature is supported.
Throws: SQLException if a database access error occurs
Since: JDK 1.2 (JDK 1.1.x developers: read the new overview for jdbcPreparedStatement)
See Also: jdbcStatement
Parameters: sql ignored
Throws: SQLException always
In general, parameter values remain in force for repeated use of a
statement. Setting a parameter value automatically clears its
previous value. However, in some cases it is useful to immediately
release the resources used by the current parameter values; this can
be done by calling the method clearParameters
.
Throws: SQLException if a database access error occurs
Throws: SQLException if a database access error occurs
PreparedStatement
object, which may be any kind of SQL statement.
Some prepared statements return multiple results; the
execute
method handles these complex statements as well
as the simpler form of statements handled by the methods
executeQuery
and executeUpdate
.
The execute
method returns a boolean
to
indicate the form of the first result. You must call either the method
getResultSet
or getUpdateCount
to retrieve the result; you must call getMoreResults
to
move to any subsequent result(s).
Including 1.8.0, prepared statements do not generate multiple fetchable results.
In future versions, it will be possible that statements generate multiple fetchable results under certain conditions.
Returns: true
if the first result is a ResultSet
object; false
if the first result is an update
count or there is no result
Throws: SQLException if a database access error occurs or an argument is supplied to this method
See Also: jdbcStatement jdbcStatement jdbcStatement jdbcStatement
Parameters: sql ignored
Returns: nothing
Throws: SQLException always
int
elements of the array that is returned are ordered
to correspond to the commands in the batch, which are ordered
according to the order in which they were added to the batch.
The elements in the array returned by the method executeBatch
may be one of the following:
SUCCESS_NO_INFO
-- indicates that the command was
processed successfully but that the number of rows affected is
unknown
If one of the commands in a batch update fails to execute properly,
this method throws a BatchUpdateException
, and a JDBC
driver may or may not continue to process the remaining commands in
the batch. However, the driver's behavior must be consistent with a
particular DBMS, either always continuing to process commands or never
continuing to process commands. If the driver continues processing
after a failure, the array returned by the method
BatchUpdateException.getUpdateCounts
will contain as many elements as there are commands in the batch, and
at least one of the elements will be the following:
EXECUTE_FAILED
-- indicates that the command failed
to execute successfully and occurs only if a driver continues to
process commands after a command fails
A driver is not required to implement this method.
The possible implementations and return values have been modified in
the Java 2 SDK, Standard Edition, version 1.3 to
accommodate the option of continuing to proccess commands in a batch
update after a BatchUpdateException
obejct has been thrown.
Starting with HSQLDB 1.7.2, this feature is supported.
HSQLDB stops execution of commands in a batch when one of the commands results in an exception. The size of the returned array equals the number of commands that were executed successfully.
When the product is built under the JAVA1 target, an exception is never thrown and it is the responsibility of the client software to check the size of the returned update count array to determine if any batch items failed. To build and run under the JAVA2 target, JDK/JRE 1.3 or higher must be used.
Returns: an array of update counts containing one element for each command in the batch. The elements of the array are ordered according to the order in which commands were added to the batch.
Throws: SQLException if a database access error occurs or the
driver does not support batch statements. Throws
{@link java.sql.BatchUpdateException}
(a subclass of java.sql.SQLException
) if one of the commands
sent to the database fails to execute properly or attempts to return a
result set.
Since: JDK 1.3 (JDK 1.1.x developers: read the new overview for jdbcStatement)
PreparedStatement
object
and returns the ResultSet
object generated by the query.
Returns: a ResultSet
object that contains the data produced
by the query; never null
Throws: SQLException if a database access error occurs or the SQL
statement does not return a ResultSet
object
Parameters: sql ignored
Returns: nothing
Throws: SQLException always
PreparedStatement
object, which must be an SQL INSERT
,
UPDATE
or DELETE
statement; or an SQL
statement that returns nothing, such as a DDL statement.
Returns: either (1) the row count for INSERT
,
UPDATE
, or DELETE
statements or (2) 0 for SQL statements that
return nothing
Throws: SQLException if a database access error occurs or the SQL
statement returns a ResultSet
object
Parameters: sql ignored
Returns: nothing
Throws: SQLException always
ResultSetMetaData
object that contains
information about the columns of the ResultSet
object
that will be returned when this PreparedStatement
object
is executed.
Because a PreparedStatement
object is precompiled, it is
possible to know about the ResultSet
object that it will
return without having to execute it. Consequently, it is possible
to invoke the method getMetaData
on a
PreparedStatement
object rather than waiting to execute
it and then invoking the ResultSet.getMetaData
method
on the ResultSet
object that is returned.
NOTE: Using this method may be expensive for some drivers due to the lack of underlying DBMS support.
Since 1.7.2, this feature is supported. If the statement generates an update count, then null is returned.
Returns: the description of a ResultSet
object's columns or
null
if the driver cannot return a
ResultSetMetaData
object
Throws: SQLException if a database access error occurs
Since: JDK 1.2 (JDK 1.1.x developers: read the new overview for jdbcPreparedStatement)
PreparedStatement
object's parameters.
Since 1.7.2, this feature is supported.
Returns: a ParameterMetaData
object that contains information
about the number, types and properties of this
PreparedStatement
object's parameters
Throws: SQLException if a database access error occurs
Since: JDK 1.4, HSQL 1.7.0
See Also: java.sql.ParameterMetaData
Array
object.
The driver converts this to an SQL ARRAY
value when it
sends it to the database.
HSQLDB 1.7.2 does not support the SQL ARRAY type. Calling this method throws an exception.
Parameters: i the first parameter is 1, the second is 2, ... x an Array
object that maps an SQL ARRAY
value
Throws: SQLException if a database access error occurs
Since: JDK 1.2 (JDK 1.1.x developers: read the new overview for jdbcPreparedStatement)
LONGVARCHAR
parameter, it may be more practical to send it via a
java.io.InputStream
. Data will be read from the stream
as needed until end-of-file is reached. The JDBC driver will
do any necessary conversion from ASCII to the database char format. Note: This stream object can either be a standard Java stream object or your own subclass that implements the standard interface.
This method uses the default platform character encoding to convert bytes from the stream into the characters of a String. In the future this is likely to change to always treat the stream as ASCII.
Before HSQLDB 1.7.0, setAsciiStream
and
setUnicodeStream
were identical.
Parameters: parameterIndex the first parameter is 1, the second is 2, ... x the Java input stream that contains the ASCII parameter value length the number of bytes in the stream
Throws: SQLException if a database access error occurs
java.math.BigDecimal
value.
The driver converts this to an SQL NUMERIC
value when
it sends it to the database.
Parameters: parameterIndex the first parameter is 1, the second is 2, ... x the parameter value
Throws: SQLException if a database access error occurs
LONGVARBINARY
parameter, it may be more practical to send it via a
java.io.InputStream
object. The data will be read from the
stream as needed until end-of-file is reached.
Note: This stream object can either be a standard Java stream object or your own subclass that implements the standard interface.
Since 1.7.2, this method works according to the standard.
Parameters: parameterIndex the first parameter is 1, the second is 2, ... x the java input stream which contains the binary parameter value length the number of bytes in the stream
Throws: SQLException if a database access error occurs
Blob
object.
The driver converts this to an SQL BLOB
value when it
sends it to the database.
Previous to 1.7.2, this feature was not supported.
Since 1.7.2, setBlob is supported. With 1.7.2, setting Blob objects is limited to those of length less than or equal to Integer.MAX_VALUE. In 1.7.2, setBlob(i,x) is roughly equivalent (null and length handling not shown) to:
setBinaryStream(i, x.getBinaryStream(), (int) x.length());
Parameters: i the first parameter is 1, the second is 2, ... x a Blob
object that maps an SQL BLOB
value
Throws: SQLException if a database access error occurs
Since: JDK 1.2 (JDK 1.1.x developers: read the new overview for jdbcPreparedStatement)
boolean
value. The driver converts this to an SQL BIT
value
when it sends it to the database.
Since 1.7.2, HSQLDB uses the BOOLEAN type instead of BIT, as per SQL 200n (SQL 3).
Parameters: parameterIndex the first parameter is 1, the second is 2, ... x the parameter value
Throws: SQLException if a database access error occurs
byte
value.
The driver converts this to an SQL TINYINT
value when
it sends it to the database.
Parameters: parameterIndex the first parameter is 1, the second is 2, ... x the parameter value
Throws: SQLException if a database access error occurs
VARBINARY
or
LONGVARBINARY
(depending on the argument's size relative
to the driver's limits on VARBINARY
values) when it
sends it to the database.
Including 1.7.2, HSQLDB stores all XXXBINARY values the same way; there is no appreciable difference between BINARY, VARBINARY and LONGVARBINARY.
Parameters: paramIndex the first parameter is 1, the second is 2, ... x the parameter value
Throws: SQLException if a database access error occurs
Reader
object, which is the given number of characters long.
When a very large UNICODE value is input to a LONGVARCHAR
parameter, it may be more practical to send it via a
java.io.Reader
object. The data will be read from the
stream as needed until end-of-file is reached. The JDBC driver will
do any necessary conversion from UNICODE to the database char format.
Note: This stream object can either be a standard Java stream object or your own subclass that implements the standard interface.
HSQLDB stores CHARACTER and related SQL types as Unicode so this method does not perform any conversion.
Parameters: parameterIndex the first parameter is 1, the second is 2, ... reader the java.io.Reader
object that contains the
Unicode data length the number of characters in the stream
Throws: SQLException if a database access error occurs
Since: JDK 1.2 (JDK 1.1.x developers: read the new overview for jdbcPreparedStatement)
Clob
object.
The driver converts this to an SQL CLOB
value when it
sends it to the database.
Previous to 1.7.2, this feature was not supported.
Since 1.7.2, setClob is supported. With 1.7.2, setting Blob objects is limited to those of length less than or equal to Integer.MAX_VALUE. In 1.7.2, setClob(i,x) is rougly equivalent (null and length handling not shown) to:
setCharacterStream(i, x.getCharacterStream(), (int) x.length());
Parameters: i the first parameter is 1, the second is 2, ... x a Clob
object that maps an SQL CLOB
value
Throws: SQLException if a database access error occurs
Since: JDK 1.2 (JDK 1.1.x developers: read the new overview for jdbcPreparedStatement)
java.sql.Date
value. The driver converts this
to an SQL DATE
value when it sends it to the database.
Parameters: parameterIndex the first parameter is 1, the second is 2, ... x the parameter value
Throws: SQLException if a database access error occurs
java.sql.Date
value, using the given Calendar
object. The driver uses
the Calendar
object to construct an SQL DATE
value,which the driver then sends to the database. With a
a Calendar
object, the driver can calculate the date
taking into account a custom timezone. If no
Calendar
object is specified, the driver uses the default
timezone, which is that of the virtual machine running the
application.
Parameters: parameterIndex the first parameter is 1, the second is 2, ... x the parameter value cal the Calendar
object the driver will use
to construct the date
Throws: SQLException if a database access error occurs
Since: JDK 1.2 (JDK 1.1.x developers: read the new overview for jdbcPreparedStatement)
double
value.
The driver converts this to an SQL DOUBLE
value when it
sends it to the database.
Since 1.7.1, HSQLDB handles Java positive/negative Infinity
and NaN double
values consistent with the Java Language
Specification; these special values are now correctly stored
to and retrieved from the database.
Parameters: parameterIndex the first parameter is 1, the second is 2, ... x the parameter value
Throws: SQLException if a database access error occurs
Since 1.7.0, the implementation follows the standard behaviour by overriding the same method in jdbcStatement class.
In other words, calling this method has no effect.
Parameters: enable true
to enable escape processing;
false
to disable it
Throws: SQLException if a database access error occurs
float
value.
The driver converts this to an SQL FLOAT
value when
it sends it to the database.
Since 1.7.1, HSQLDB handles Java positive/negative Infinity
and NaN float
values consistent with the Java Language
Specification; these special values are now correctly stored
to and retrieved from the database.
Parameters: parameterIndex the first parameter is 1, the second is 2, ... x the parameter value
Throws: SQLException if a database access error occurs
int
value.
The driver converts this to an SQL INTEGER
value when
it sends it to the database.
Parameters: parameterIndex the first parameter is 1, the second is 2, ... x the parameter value
Throws: SQLException if a database access error occurs
long
value.
The driver converts this to an SQL BIGINT
value when
it sends it to the database.
Parameters: parameterIndex the first parameter is 1, the second is 2, ... x the parameter value
Throws: SQLException if a database access error occurs
NULL
. Note: You must specify the parameter's SQL type.
HSQLDB ignores the sqlType argument.
Parameters: paramIndex the first parameter is 1, the second is 2, ... sqlType the SQL type code defined in java.sql.Types
Throws: SQLException if a database access error occurs
NULL
.
This version of the method setNull
should
be used for user-defined types and REF type parameters. Examples
of user-defined types include: STRUCT, DISTINCT, JAVA_OBJECT, and
named array types.
Note: To be portable, applications must give the SQL type code and the fully-qualified SQL type name when specifying a NULL user-defined or REF parameter. In the case of a user-defined type the name is the type name of the parameter itself. For a REF parameter, the name is the type name of the referenced type. If a JDBC driver does not need the type code or type name information, it may ignore it. Although it is intended for user-defined and Ref parameters, this method may be used to set a null parameter of any JDBC type. If the parameter does not have a user-defined or REF type, the given typeName is ignored.
HSQLDB ignores the sqlType and typeName arguments.
Parameters: paramIndex the first parameter is 1, the second is 2, ... sqlType a value from java.sql.Types
typeName the fully-qualified name of an SQL user-defined type;
ignored if the parameter is not a user-defined type or REF
Throws: SQLException if a database access error occurs
Since: JDK 1.2 (JDK 1.1.x developers: read the new overview for jdbcPreparedStatement)
The second argument must be an object type; for integral values, the
java.lang
equivalent objects should be used.
The given Java object will be converted to the given targetSqlType
before being sent to the database.
If the object has a custom mapping (is of a class implementing the
interface SQLData
),
the JDBC driver should call the method SQLData.writeSQL
to
write it to the SQL data stream.
If, on the other hand, the object is of a class implementing
Ref
, Blob
, Clob
,
Struct
, or Array
, the driver should pass it
to the database as a value of the corresponding SQL type.
Note that this method may be used to pass database-specific abstract data types.
Inculding 1.7.1,this method was identical to {@link #setObject(int, Object, int) setObject(int, Object, int)}. That is, this method simply called setObject(int, Object, int), ignoring the scale specification.
Since 1.7.2, this method supports the conversions listed in the conversion table B-5 of the JDBC 3 specification. The scale argument is not used.
Parameters: parameterIndex the first parameter is 1, the second is 2, ... x the object containing the input parameter value targetSqlType the SQL type (as defined in java.sql.Types) to be
sent to the database. The scale argument may further qualify this type. scale for java.sql.Types.DECIMAL or java.sql.Types.NUMERIC types,
this is the number of digits after the decimal point. For all
other types, this value will be ignored.
Up to and including HSQLDB 1.7.0, this parameter is ignored.
Throws: SQLException if a database access error occurs
See Also: java.sql.Types jdbcPreparedStatement
setObject
above, except that it assumes a scale of zero.
Since 1.7.2, this method supports conversions listed in the conversion table B-5 of the JDBC 3 specification.
Parameters: parameterIndex the first parameter is 1, the second is 2, ... x the object containing the input parameter value targetSqlType the SQL type (as defined in java.sql.Types) to be sent to the database
Throws: SQLException if a database access error occurs
See Also: jdbcPreparedStatement
The second parameter must be of type Object
; therefore,
the java.lang
equivalent objects should be used for
built-in types.
The JDBC specification specifies a standard mapping from
Java Object
types to SQL types. The given argument
will be converted to the corresponding SQL type before being
sent to the database.
Note that this method may be used to pass datatabase-
specific abstract data types, by using a driver-specific Java
type. If the object is of a class implementing the interface
SQLData
, the JDBC driver should call the method
SQLData.writeSQL
to write it to the SQL data stream.
If, on the other hand, the object is of a class implementing
Ref
, Blob
, Clob
,
Struct
, or Array
, the driver should pass
it to the database as a value of the corresponding SQL type.
This method throws an exception if there is an ambiguity, for example, if the object is of a class implementing more than one of the interfaces named above.
Since 1.7.2, this method supports conversions listed in the conversion table B-5 of the JDBC 3 specification.
Parameters: parameterIndex the first parameter is 1, the second is 2, ... x the object containing the input parameter value
Throws: SQLException if a database access error occurs or the type of the given object is ambiguous
REF(<structured-type>)
value.
The driver converts this to an SQL REF
value when it
sends it to the database.
HSQLDB 1.7.2 does not support the SQL REF type. Calling this method throws an exception.
Parameters: i the first parameter is 1, the second is 2, ... x an SQL REF
value
Throws: SQLException if a database access error occurs
Since: JDK 1.2 (JDK 1.1.x developers: read the new overview for jdbcPreparedStatement)
short
value. The driver converts this to an SQL SMALLINT
value when it sends it to the database.
Parameters: parameterIndex the first parameter is 1, the second is 2, ... x the parameter value
Throws: SQLException if a database access error occurs
String
value.
The driver converts this
to an SQL VARCHAR
or LONGVARCHAR
value
(depending on the argument's
size relative to the driver's limits on VARCHAR
values)
when it sends it to the database.
Including 1.7.2, HSQLDB stores all XXXCHAR values as java.lang.String objects; there is no appreciable difference between CHAR, VARCHAR and LONGVARCHAR.
Parameters: parameterIndex the first parameter is 1, the second is 2, ... x the parameter value
Throws: SQLException if a database access error occurs
java.sql.Time
value. The driver converts this to an SQL TIME
value when it
sends it to the database.
Parameters: parameterIndex the first parameter is 1, the second is 2, ... x the parameter value
Throws: SQLException if a database access error occurs
java.sql.Time
value, using the given Calendar
object. The driver uses
the Calendar
object to construct an SQL TIME
value, which the driver then sends to the database. With a
a Calendar
object, the driver can calculate the time
taking into account a custom timezone. If no
Calendar
object is specified, the driver uses the default
timezone, which is that of the virtual machine running the
application.
Parameters: parameterIndex the first parameter is 1, the second is 2, ... x the parameter value cal the Calendar
object the driver will use
to construct the time
Throws: SQLException if a database access error occurs
Since: JDK 1.2 (JDK 1.1.x developers: read the new overview for jdbcPreparedStatement)
java.sql.Timestamp
value. The driver converts this to
an SQL TIMESTAMP
value when it sends it to the
database.
Parameters: parameterIndex the first parameter is 1, the second is 2, ... x the parameter value
Throws: SQLException if a database access error occurs
java.sql.Timestamp
value, using the given Calendar
object. The driver uses
the Calendar
object to construct an SQL TIMESTAMP
value, which the driver then sends to the database. With a
Calendar
object, the driver can calculate the timestamp
taking into account a custom timezone. If no
Calendar
object is specified, the driver uses the default
timezone, which is that of the virtual machine running the application.
Parameters: parameterIndex the first parameter is 1, the second is 2, ... x the parameter value cal the Calendar
object the driver will use
to construct the timestamp
Throws: SQLException if a database access error occurs
Since: JDK 1.2 (JDK 1.1.x developers: read the new overview for jdbcPreparedStatement)
Deprecated: Sun does not include a reason, but presumably this is because setCharacterStream is now prefered
Sets the designated parameter to the given input stream, which will have the specified number of bytes. A Unicode character has two bytes, with the first byte being the high byte, and the second being the low byte. When a very large Unicode value is input to aLONGVARCHAR
parameter, it may be more practical to send it via a
java.io.InputStream
object. The data will be read from the
stream as needed until end-of-file is reached. The JDBC driver will
do any necessary conversion from Unicode to the database char format.
Note: This stream object can either be a standard Java stream object or your own subclass that implements the standard interface.
Since 1.7.0, this method complies with behavior as defined by the JDBC3 specification.
Parameters: parameterIndex the first parameter is 1, the second is 2, ... x a java.io.InputStream
object that contains the
Unicode parameter value as two-byte Unicode characters length the number of bytes in the stream
Throws: SQLException if a database access error occurs
java.net.URL
value. The driver converts this to an SQL DATALINK
value
when it sends it to the database.
HSQLDB 1.7.2 does not support the DATALINK SQL type for which this method is intended. Calling this method throws an exception.
Parameters: parameterIndex the first parameter is 1, the second is 2, ... x the java.net.URL
object to be set
Throws: SQLException if a database access error occurs
Since: JDK 1.4, HSQL 1.7.0
The representation is of the form:
class-name@hash[sql=[char-sequence], parameters=[p1, ...pi, ...pn]]
p1, ...pi, ...pn are the String representations of the currently set parameter values that will be used with the non-batch execution methods.
Returns: a String representation of this object