[ 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 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? > > 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 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." > > 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 developer >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: 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
