Thread: JDBC Scrollable ResultSet

Are first() and previous() fully implemented?

My tests indicate that first() will correctly return false if the resultSet(TYPE_SCROLL_INSENSITIVE,CONCUR_READ_ONLY) is empty, but if I have called next() several times on a non-empty resultSet then a call to first() doesn't seem to have any effect, even though it returns true.

pg 7.3.2, latest stable pg73jdbc2

Does anyone have a smart workaround?
Thanks, Jonathan

On Sat, Sep 13, 2003 at 11:03:02AM +0300, jonathan.lister@vaisala.com wrote:
> Are first() and previous() fully implemented?
>
> My tests indicate that first() will correctly return false if the
> resultSet(TYPE_SCROLL_INSENSITIVE,CONCUR_READ_ONLY) is empty, but if I have
> called next() several times on a non-empty resultSet then a call to first()
> doesn't seem to have any effect, even though it returns true.
>
> pg 7.3.2, latest stable pg73jdbc2
>
> Does anyone have a smart workaround?

Are you also using setFetchSize()? I've noticed that the cursor-based-fetch
implementation that gets used with a non-zero fetchsize doesn't look like it
will work correctly with scrollable resultsets.

-O

My apologies,
further tests show that the complex SQL wasn't doing quite what I expected.
Replacing the SQL with something really simple shows that first() and previous() work just fine!
I should have done that test before.
Jonathan

-----Original Message-----
From: Oliver Jowett [mailto:oliver@opencloud.com]
Sent: 14 September 2003 02:30
To: jonathan.lister@vaisala.com
Cc: pgsql-jdbc@postgresql.org
Subject: Re: [JDBC] JDBC Scrollable ResultSet

On Sat, Sep 13, 2003 at 11:03:02AM +0300, jonathan.lister@vaisala.com wrote:
> Are first() and previous() fully implemented?
>
> My tests indicate that first() will correctly return false if the
> resultSet(TYPE_SCROLL_INSENSITIVE,CONCUR_READ_ONLY) is empty, but if I have
> called next() several times on a non-empty resultSet then a call to first()
> doesn't seem to have any effect, even though it returns true.
>
> pg 7.3.2, latest stable pg73jdbc2
>
> Does anyone have a smart workaround?

Are you also using setFetchSize()? I've noticed that the cursor-based-fetch
implementation that gets used with a non-zero fetchsize doesn't look like it
will work correctly with scrollable resultsets.

-O

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
      joining column's datatypes do not match