Mailing-List: contact derby-user-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Derby Discussion" <derby-user@db.apache.org>
Received-SPF: pass (asf.osuosl.org: local policy)
Date: Fri, 21 Jul 2006 11:45:30 +0200
From: Andreas Korneliussen <Andreas.Korneliussen@Sun.COM>
Subject: Re: Embedded driver support for ResultSet.getRow
In-reply-to: <loom.20060721T083319-800@post.gmane.org>
To: Derby Discussion <derby-user@db.apache.org>
Reply-to: Andreas.Korneliussen@Sun.COM
Message-id: <44C0A23A.8080500@sun.com>
Organization: Sun Microsystems
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
User-Agent: Thunderbird 1.5.0.2 (X11/20060427)
References: <loom.20060721T083319-800@post.gmane.org>

Matt Frantz wrote:
> I am porting an application from PostgreSQL to Derby.  I use ResultSet.getRow()
> to keep track of whether a particular row has been processed.  However, I get an
> error like this:
> 
> The 'getRow()' method is only allowed on scroll cursors
> 

I could not find anything in JavaDoc for ResultSet.getRow() which 
indicates that getRow() should not be allowed on forward-only result 
sets. So this may be a bug in Derby.

> It seems that even a forward iterator should be able to keep count of the rows,
> so this method should be supported.  Am I mistaken about the semantics of this
> method?  Is there another way to know which row I'm on without using scrolling
> ResultSets, which (according to the docs) read the results into memory?
> 

The docs are out-of-date. I am not sure exactly which version, however 
at least since 10.1.2 scrollable resultsets will back the data to disk 
(to a temporary table) if the result set is huge.

Regards
Andreas

> Regards,
> Matt Frantz
> 
>