Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Derby Development" <derby-dev@db.apache.org>
Received-SPF: neutral (hermes.apache.org: local policy)
Message-ID: <41DAE0A6.3030808@debrunners.com>
Date: Tue, 04 Jan 2005 10:29:58 -0800
From: Daniel John Debrunner <djd@debrunners.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:1.4.1) Gecko/20031008
MIME-Version: 1.0
To: Derby Development <derby-dev@db.apache.org>
Subject: Re: Position of the ResultSet after updateRow?
References: <41DABA6C.7F334B5C@Remulak.Net>
In-Reply-To: <41DABA6C.7F334B5C@Remulak.Net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Mamta Satoor wrote:

> Hi,
>
> Some of you might recall the discussion on where the ResultSet should be
> positioned after deleteRow and the conclusion that it will be placed right
> before the next row in the ResultSet.
>
> My question is about ResultSet position after updateRow. An updateRow
> can make the row not qualify for the original select query.

Can anyone from the Sun JDBC team comment on how updateRow() and
insertRow() are intended to behave when they modify or create rows that
would not qualify according to the SQL query that created the ResultSet?

Reading between the lines in the JDBC book seems to imply that the
updated or inserted row are always part of the ResultSet, even though a
subsequent execution would not return that row.
I can see this approach makes sense for going through a list of items in
an application. Say all items with a price <= 10.0, and modifying the
price of some to be > 10.0, as a user I might expect to see the newly
modified row remain in my view, rather than just disappear.

Dan.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFB2uCmIv0S4qsbfuQRAtagAJwOkXd7mu0nLteBa26X4tqGY324RgCdE8ld
BXWcUymBmC0cK0Yh9dwPE84=
=YSr2
-----END PGP SIGNATURE-----