Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <21684570.1151143591831.JavaMail.jira@brutus>
Date: Sat, 24 Jun 2006 10:06:31 +0000 (GMT+00:00)
From: "Knut Anders Hatlen (JIRA)" <derby-dev@db.apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Updated: (DERBY-1364) Client driver does not roll back the
 effects of a stored procedure when incorrectly invoked by
 executeQuery()/executeUpdate()
In-Reply-To: <8235056.1149156509902.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

     [ http://issues.apache.org/jira/browse/DERBY-1364?page=all ]

Knut Anders Hatlen updated DERBY-1364:
--------------------------------------

    Derby Info: [Patch Available]

> Client driver does not roll back the effects of a stored procedure when incorrectly invoked by executeQuery()/executeUpdate()
> -----------------------------------------------------------------------------------------------------------------------------
>
>          Key: DERBY-1364
>          URL: http://issues.apache.org/jira/browse/DERBY-1364
>      Project: Derby
>         Type: Bug

>   Components: JDBC, Network Client
>     Versions: 10.1.2.1, 10.2.0.0
>     Reporter: Knut Anders Hatlen
>     Assignee: Knut Anders Hatlen
>     Priority: Minor
>      Fix For: 10.2.0.0
>  Attachments: derby-1364-v1.diff, derby-1364-v1.stat
>
> When executing a stored procedure with executeQuery() and the proc
> doesn't return exactly one result set, the query should fail and the
> statement should be rolled back. Embedded does this correctly.
> The client driver, however, does not roll back the statement, so the
> effects of statements executed on nested connections in the stored
> procedure are still visible. The reason for this is that the network
> server executes the statement with execute() instead of
> executeQuery(), so that it succeeds on the server. The client then
> counts the number of result sets, and raises an exception if it is not
> one, but it does not roll back the effects of the stored procedure.
> verified that.)
> The same problem exists for executeUpdate(). JCC also has these
> problems.

-- 
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