[ 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 used. 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? 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 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 13.3.3.3 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." 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 developer and not the driver/database engine? > 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: 10.2.0.0 > Reporter: Rick Hillegas > Fix For: 10.2.0.0 > > 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 invocations. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
