Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <11182569.1146846268282.JavaMail.jira@brutus>
Date: Fri, 5 May 2006 16:24:28 +0000 (GMT+00:00)
From: "Andreas Korneliussen (JIRA)" <derby-dev@db.apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Updated: (DERBY-1277) Call to rs.isLast() may cause
 rs.getXXX() return values from the last row instead of the current row in
 scrollable resultsets
In-Reply-To: <22290228.1146656686438.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-1277?page=all ]

Andreas Korneliussen updated DERBY-1277:
----------------------------------------

    Derby Info: [Patch Available]

A patch is now available for review.

> Call to rs.isLast() may cause rs.getXXX() return values from the last row instead of the current row in scrollable resultsets
> -----------------------------------------------------------------------------------------------------------------------------
>
>          Key: DERBY-1277
>          URL: http://issues.apache.org/jira/browse/DERBY-1277
>      Project: Derby
>         Type: Bug

>   Components: SQL
>     Versions: 10.2.0.0, 10.1.2.1
>     Reporter: Andreas Korneliussen
>     Assignee: Andreas Korneliussen
>  Attachments: DERBY-1277.diff, DERBY-1277.stat
>
> In scrollable updatable resultset, a call to rs.isLast() may cause rs.getXXX() return values from the last row, instead of for the current row.  This may be related to the fact that on calls to isLast() the scroll insensitive resultset moves to the last row, and then moves back to the current row (see DERBY-1276 for related information). The call to isLast() seems to have a sideeffect when the resultset is updatable.
> I have test which does the following:
>         Statement stmt1 = con.createStatement(ResultSet.TYPE_SCROLL_INSENSITIVE,ResultSet.CONCUR_UPDATABLE);
>         ResultSet rs = stmt1.executeQuery("select * from testRelative");
>         
>         rs.next(); // First Record
>         System.out.println("First record is: " + rs.getString("name"));
>         rs.relative(2); // Third Record        
>         System.out.println("Third record is: " + rs.getString("name"));
>         System.out.println(" isLast=" + rs.isLast());
>         System.out.println("Third record is: " + rs.getString("name"));
> The output is:
> First record is: work1
> Third record is: work3
>  isLast=false
> Third record is: work4
> isLast()==false
> The issue may also be reproduced by applying the following patch to testRelative:
> Index: java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/testRelative.java
> ===================================================================
> --- java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/testRelative.java  (revision 399224)
> +++ java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/testRelative.java  (working copy)
> @@ -60,7 +60,7 @@
>                         pStmt.executeBatch();
>                         con.commit();
> -                       stmt1 = con.createStatement(ResultSet.TYPE_SCROLL_INSENSITIVE,ResultSet.CONCUR_READ_ONLY);
> +                       stmt1 = con.createStatement(ResultSet.TYPE_SCROLL_INSENSITIVE,ResultSet.CONCUR_UPDATABLE);
>                         rs = stmt1.executeQuery("select * from testRelative");
>                         rs.next(); // First Record

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