Return-Path: 
 <derby-dev-return-10870-apmail-db-derby-dev-archive=db.apache.org@db.apache.org>
Delivered-To: apmail-db-derby-dev-archive@www.apache.org
Received: (qmail 93390 invoked from network); 22 Nov 2005 17:46:07 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199)
  by minotaur.apache.org with SMTP; 22 Nov 2005 17:46:07 -0000
Received: (qmail 15979 invoked by uid 500); 22 Nov 2005 17:46:06 -0000
Delivered-To: apmail-db-derby-dev-archive@db.apache.org
Received: (qmail 15946 invoked by uid 500); 22 Nov 2005 17:46:05 -0000
Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:derby-dev-help@db.apache.org>
List-Unsubscribe: <mailto:derby-dev-unsubscribe@db.apache.org>
List-Post: <mailto:derby-dev@db.apache.org>
List-Id: <derby-dev.db.apache.org>
Reply-To: <derby-dev@db.apache.org>
Delivered-To: mailing list derby-dev@db.apache.org
Received: (qmail 15935 invoked by uid 99); 22 Nov 2005 17:46:05 -0000
X-ASF-Spam-Status: No, hits=1.3 required=10.0
	tests=SPF_FAIL
X-Spam-Check-By: apache.org
Received: from [192.87.106.226] (HELO ajax.apache.org) (192.87.106.226)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 22 Nov 2005 09:46:03 -0800
Received: from ajax.apache.org (ajax.apache.org [127.0.0.1])
	by ajax.apache.org (Postfix) with ESMTP id 646FD593
	for <derby-dev@db.apache.org>; Tue, 22 Nov 2005 18:45:42 +0100 (CET)
Message-ID: <1176251002.1132681542409.JavaMail.jira@ajax.apache.org>
Date: Tue, 22 Nov 2005 18:45:42 +0100 (CET)
From: "Dag H. Wanvik (JIRA)" <derby-dev@db.apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Commented: (DERBY-722) updateRow invalidates current row in
 result set
In-Reply-To: <875117272.1132620881836.JavaMail.jira@ajax.apache.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-Virus-Checked: Checked by ClamAV on apache.org
X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N

    [ http://issues.apache.org/jira/browse/DERBY-722?page=comments#action_12358267 ] 

Dag H. Wanvik commented on DERBY-722:
-------------------------------------

Testcase "Positive Test3b" in lang/updatableResultset.java tests for
this situation and states:

"Since after updateRow(), ResultSet is positioned before the next row,
getXXX will fail".

So the behavior is expected for Derby, but why? For positioned update,
the position is kept.
(ANSI says so, too, cf. 2003, section 14.10 <update
statement:positioned>, General Rule 11: "CR remains positioned on its
current row,even if an exception condition is raised during evaluation
of any <update source>")

So why does Derby behave this way for updateRow() ?


> updateRow invalidates current row in result set
> -----------------------------------------------
>
>          Key: DERBY-722
>          URL: http://issues.apache.org/jira/browse/DERBY-722
>      Project: Derby
>         Type: Bug
>   Components: Network Client, JDBC
>     Versions: 10.1.2.2, 10.1.3.0, 10.2.0.0, 10.1.2.1, 10.1.2.0, 10.1.1.2, 10.1.1.1, 10.1.1.0
>  Environment: Sun JDK 1.4.2, Solaris 10
>     Reporter: Dag H. Wanvik
>     Priority: Minor
>  Attachments: Main.java
>
> In both the network and embedded drivers, after an updateRow has been performed,
> reading the current row fails. A new next() is required to get a new valid position, as shown by the attached repro. 
> In contrast to the case for deleteRow, JDBC does not require a repositioning after an updateRow.

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