Hi,
Could you post some additional detail, including:
Driver version you are using (v1.0, v1.1, v1.2 CTP), preferably output from DatabaseMetaData.getDriverVersion().
A snippet of code you are using to call the stored procedure and process its results
The stored procedure definition
The JDBC driver manages cursors through the ResultSet APIs, so you should not need to create and return cursors from your stored procedure. Are you trying to return a cursor from the stored procedure, or just use one in the stored procedure
Thank you,
--David Olix [MSFT]
Hi,
Thank you for your thorough investigation and for providing a detailed repro.
Looking at your stored procedure, though, there are three results that you need to process: one update count for each INSERT, and a result set for the SELECT. In order to process all of the results from a statement that produces multiple results, you need to use Statement.execute() (not executeQuery()) in conjunction with Statement.getMoreResults(), Statement.getResultSet() and Statement.getUpdateCount(). You should only use Statement.executeQuery() with statements that produce a single ResultSet as their only result.
Hope this helps,
--David Olix [MSFT]
Hi,
If you're using the v1.2 CTP, which it looks like you are from your earlier posts, then you're hitting a bug where PreparedStatement.execute only returns the last update count in a series unless you set the lastUpdateCount connection property to false (it's default value is true). This is targeted to be fixed before the driver is released later this fall, possibly as early as the next CTP.
The SQL Server 2000 driver and the SQL Server 2005 driver (which also works with SQL Server 2000) are different products with different code bases. So there are some significant differences in behavior.
The JDBC spec has been consistent all along as far as I know. But quoting from https://java.sun.com/javase/6/docs/technotes/guides/jdbc/getstart/statement.html :
"The method executeQuery is designed for statements that produce a single result set, such as SELECT statements.
[...]
The method execute is used to execute statements that return more than one result set, more than one update count, or a combination of the two."
Regards,
--David Olix [MSFT]
There is another more subtle cause for this, if you aren't intending to send back multiple resultsets but are still getting the exception.
When you insert into a temp table, the number of rows affected is reported back to the client unless you use SET NOCOUNT ON. This can cause the exception when you least expect it.
I would suggest running your procedure from the development tool to make sure you're not getting this sort of message.
Happy Coding,