On 5/9/06, Knut Anders Hatlen (JIRA) <[email protected]> wrote:
Sounds good. No, I am not working on DERBY-501, so I have unassigned myself.
Satheesh
[ http://issues.apache.org/jira/browse/DERBY-1288?page=comments#action_12378720 ]
> 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?
Sounds good. No, I am not working on DERBY-501, so I have unassigned myself.
Satheesh
> 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
