Dave Cramer <Dave@micro-automation.net> writes:
> This is more or less the same problem, you still need to cache rows, and
> know where you are in the result set, cursors make it easier because you
> can move absolute, or relative in a cursor. Also as it stands now there
> is a move end which as it turns out gives you the number of rows in the
> resultset.
>
> Just for my elucidation, is there someone working on an implementation?
>
> Nic, you mentioned you would have a shot at it?
Yes. I'll bash out an implementation over the w/e.
Basically, I like your solution: use setFetchSize to control when a
cursor is used.
I am not so concerened about JDBC 2.0 compliance: the main thing is
that one ought to be able to _not_ read in a million rows if that's
what's in the table you're selecting.
setFetchSize is perfect for that.
Once that's done then people can test it and maybe improve it so that
it's jdbc 2.0 compliant and maybe so that the use of caching could be
guessed (don't ask me how yet, that's not the point).
If people like it, maybe it will be accepted.
Nic
