Can't implement this directly, as then you can't use callable statements
on JDK-1.3.1, which unfortunately isn't EOL'd yet, and still present
quite a bit out there in the wild (Websphere, FreeBSD, anyone?)
JDBC 2.0 The cancelRowUpdates() method may be called after calling an
updateXXX() method(s) and before calling updateRow() to rollback the
updates made to a row.
JDBC 2.0 The cancelRowUpdates() method may be called after calling an
updateXXX() method(s) and before calling updateRow() to rollback the
updates made to a row.
Prepares a statement on the client, using client-side emulation
(irregardless of the configuration property 'useServerPrepStmts')
with the same semantics as the java.sql.Connection.prepareStatement()
method with the same argument types.
Prepares a statement on the client, using client-side emulation
(irregardless of the configuration property 'useServerPrepStmts')
with the same semantics as the java.sql.Connection.prepareStatement()
method with the same argument types.
Prepares a statement on the client, using client-side emulation
(irregardless of the configuration property 'useServerPrepStmts')
with the same semantics as the java.sql.Connection.prepareStatement()
method with the same argument types.
Prepares a statement on the client, using client-side emulation
(irregardless of the configuration property 'useServerPrepStmts')
with the same semantics as the java.sql.Connection.prepareStatement()
method with the same argument types.
Prepares a statement on the client, using client-side emulation
(irregardless of the configuration property 'useServerPrepStmts')
with the same semantics as the java.sql.Connection.prepareStatement()
method with the same argument types.
Prepares a statement on the client, using client-side emulation
(irregardless of the configuration property 'useServerPrepStmts')
with the same semantics as the java.sql.Connection.prepareStatement()
method with the same argument types.
In some cases, it is desirable to immediately release a Connection's
database and JDBC resources instead of waiting for them to be
automatically released (cant think why off the top of my head) Note:
A Connection is automatically closed when it is garbage collected.
In some cases, it is desirable to immediately release a ResultSet
database and JDBC resources instead of waiting for this to happen when it
is automatically closed.
In many cases, it is desirable to immediately release a Statement's
database and JDBC resources instead of waiting for this to happen when it
is automatically closed.
The method commit() makes all changes made since the previous
commit/rollback permanent and releases any database locks currently held
by the Connection.
Thrown when a client requests a connection-level feature that isn't available
for this particular distribution of Connector/J (currently only used by code
that is export-controlled).
Implementors of this interface can be installed via the
"connectionLifecycleInterceptors" configuration property and receive
events and alter behavior of "lifecycle" methods on our connection
implementation.
Implement this interface, and pass the class name as the
'propertiesTransform' property in your JDBC URL, and the driver will pass the
properties it has parsed to your transform implementation so that you can
modify/substitute/add any that you desire.
Creates a communications link failure message to be used
in CommunicationsException that (hopefully) has some better
information and suggestions based on heuristics.