But this is not an optional exception, so I guess the real answer is the the driver is not JDBC 3 compliant, it would not pas the tests, and thus cannot be called a jdbc driver.
robert engels wrote:
Here is the javadoc. The method explicitly states when it throws an exception:
/**
* Sets the number of seconds the driver will wait for a * <code>Statement</code> object to execute to the given number of seconds.
* If the limit is exceeded, an <code>SQLException</code> is thrown.
*
* @param seconds the new query timeout limit in seconds; zero means * there is no limit
* @exception SQLException if a database access error occurs
* or the condition seconds >= 0 is not satisfied
* @see #getQueryTimeout
*/
Even if this is not sufficient, it worked this way in the previous driver versions - so I guess there should be evidence the other way in order to change it.
This is not a problem when using the 8.3 driver against an 8.3 database - only seems to happen with a 8.1 db (maybe 8.2???)
I did read the javadoc .. It does not say that the driver should silently do nothing if query timeouts are unsupported.
The Java 6 javadoc is somewhat more explicit:
Sets the number of seconds the driver will wait for a Statement object to execute to the given number of seconds. If the limit is exceeded, an SQLException is thrown. A JDBC driver must apply this limit to the execute, executeQuery and executeUpdate methods. JDBC driver implementations may also apply this limit to ResultSet methods (consult your driver vendor documentation for details).
Drivers "must apply this limit", but we cannot currently do that.
The argument here is that asking the driver to do something it can't actually do is a "database access error". So you get a SQLException if you ask for a non-zero timeout, since that is not currently supported.
-O