Am Montag, 29. März 2004 18:30 schrieb Alexander Staubo:
> Earlier versions of the PostgreSQL JDBC driver do not stream data from
> the back end: they fetch everything in one go.
>
> The PostgreSQL 7.4 JDBC driver supports JDBC's setFetchSize()
> operation, and will use PostgreSQL cursors internally. If you set the
> fetch size to something >0, it will correctly [*] and transparently
> stream data on demand. The driver works perfectly with earlier
> versions of PostgreSQL.
>
> With earlier versions of the driver, you can emulate the behaviour by
> first doing this:
>
> stmt.executeUpdate("declare foo cursor for select * from bar");
>
> and then for each batch, as an executeQuery():
>
> rs = stmt.executeQuery("fetch forward 200 from foo");
>
> and when you're done with the cursor,
>
> stmt.executeUpdate("close foo");
By chance i'am currently at the same point, unfortunately i don't get it
working as expected.
-after calling ResultSet.last() the getRow() still reflects the fetchsize (how
to get the number of records for e.g. a progress-bar?)
-calling "ResultSet.next()" at the "last" fetched record does not fetch more
results automatically, Statement.fetchMoreResults() gives me null-pointer -
how do i actually get the next fetch?
-according to the documentation only "FETCH_FORWARD" is supported, which is
not always suitable
Does it have some meaning that it only works if
Connection.setAutoCommit(false) is used?
I had a quick look through the sources and found the term
"server-prepared-statement" is used under certain conditions - what's this
for?
I was also thinking about using the "SELECT ... LIMIT x OFFSET y" instead, but
this might lead to unexpected side effects if multiple users are changing
data - the user gets only a momentary snapshot then, if the order has changed
in between some records will never be seen, others twice and so on.
Any nice idea to solve this?
(Im using postgres 7.3 + a recent snapshot from cvs-jdbc-driver)
Guido