Using Statement.close with unprocessed results

The JDBC specification is somewhat vague on how a driver should behave when you call Statement.execute and later call close on that same statement object without processing all of the results (update counts and ResultSets) returned by the Statement.

For example, assume that there is a stored procedure on the database that does seven row inserts. An application then executes that stored procedure using a Statement.execute. In this case, a Sybase database returns seven update counts (one for each inserted row) to the application. In normal JDBC application logic, you would process those update counts in a loop using the getMoreResults, getResultSet and getUpdateCount methods. These are clearly explained on the Sun Web page for Java developers in the javadocs for the java.sql.* package.

However, an application programmer might incorrectly choose to call Statement.close before reading through all of the returned update counts. In this case, jConnect sends a cancel to the database, which can have unexpected and unwanted side effects.

In this particular example, if the application calls Statement.close before the database has completed the inserts, the database might not execute all of the inserts. It might stop, for example, after only five rows are inserted because the cancel is processed on the database before the stored procedure completes.

The missing inserts would not be reported to you in this case. Future releases of jConnect may throw a SQLException when you try to close a Statement when there are still unprocessed results, but until then, jConnect programmers are strongly advised to adhere to the following guidelines: