db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rick Hillegas (JIRA)" <derby-...@db.apache.org>
Subject [jira] Commented: (DERBY-1288) Bring Derby into JDBC compliance by supporting executeQuery() on escaped procedure invocations
Date Thu, 04 May 2006 20:44:17 GMT
    [ http://issues.apache.org/jira/browse/DERBY-1288?page=comments#action_12377886 ] 

Rick Hillegas commented on DERBY-1288:

Mousing in Lance's response:

>    [ http://issues.apache.org/jira/browse/DERBY-1288?page=comments#action_12377874 ]

>Daniel John Debrunner commented on DERBY-1288:
>dan >> If multiple result sets are returned when should any error be thrown, before
the execution starts or once the system detects that multiple result sets are returned?
>lance > This would probably be implementation defined depending on the mechanism being
>This is where I get confused, if this is implementation defined then how can returning
a single ResultSet not be implementation defined as well? Is there a good clear definition
of the behaviour you would like to see?
I am not sure how JDBC can guarantee when/how a driver/backend determines whether a ResultSet
or an update count (or both) is coming down the wire especially given some vendors support
java based procedures, standard stored procedures.

>As an example, if the behaviour is implementation defined then it seems to me that a procedure
that was defined with DYNAMIC RESULT SETS 4 could be rejected at compile time, even though
it could at runtime only return a single result set. This seems a valid implementation
possibly but there is no way to determine this on vendors such as Sybase/MS SQL Server with
t-sql procedures

>Similarly a procedure defined with DYNAMIC RESULT SETS 1 could return zero result sets,
and thus the executeQuery() has to thrown an exception.
>As I've said in DERBY-501, section of JDBC 3.0 states:
>"If the type or number of results returned by a CallableStatement object are not
>known until run time, the CallableStatement object should be executed with the
>method execute."
agree but the wording above has nothing to do with the J2EE requirement which has been there
as i said since the J2EE 1.2 spec.  All i have done is move the wording from the J2EE spec
to the compliance section of the JDBC 4 spec and start pruning things that are already required.

Now myself, i always use execute() with my sprocs but that is me.

>Now with Derby Java procedures, the engine does *not* know until runtime how many ResultSets
are returned, so it seems to me that this implies execute() must be used and so executeQuery
is invalid.
>Maybe I'm reading this the wrong way, and "known" applies to the knowledge of the application
>and not the driver/database engine?
In this case it would apply to the application developer.  So the intent is that the developer
using a sproc with a stored procedure would only choose executeQuery() when they can guarantee
a single ResultSet down the wire and executeUpdate() when no ResultSets will be sent down
the wire and use execute() otherwise.

> Bring Derby into JDBC compliance by supporting executeQuery() on escaped procedure invocations
> ----------------------------------------------------------------------------------------------
>          Key: DERBY-1288
>          URL: http://issues.apache.org/jira/browse/DERBY-1288
>      Project: Derby
>         Type: Improvement

>   Components: JDBC
>     Versions:
>     Reporter: Rick Hillegas
>      Fix For:

> The following statement raises an error in Derby:
>   statement.executeQuery( "{call foo()}" );
> although this statement works:
>   statement.executeUpdate( "{call foo()}" );
> According to section 6.4 of the latest draft of the JDBC4 Compliance chapter, both statements
are supposed to work in order to claim Java EE JDBC Compliance.
> We need to bring Derby into compliance by supporting executeQuery() on escaped procedure

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:

View raw message