[ http://issues.apache.org/jira/browse/DERBY-1288?page=comments#action_12378720 ]
Knut Anders Hatlen commented on DERBY-1288: ------------------------------------------- Satheesh Bandaram wrote: >> What Derby currently does, is >> >> executeQuery: >> >> fails whenever a stored procedure is invoked (both embedded and >> client) > > Is that true? No, sorry about that. Embedded fails whenever a stored procedure is invoked, but the client fails only when no results are returned. > According to DERBY-501, executeQuery works for single ResultSet > stored procedure for client, but fails for embedded. Since Rick > agreed that fixing this would also fix DERBY-501, one of these > should be marked a duplicate. OK, we can close this one as duplicate and create a new one for executeUpdate(). I see that DERBY-501 is assigned to you. Are you actively working on it? > 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 > Assignee: Knut Anders Hatlen > 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
