Hi,
Daniel John Debrunner <[EMAIL PROTECTED]> writes:
>>> JDBC says you might see it, due to the "as the rows are retrieved".
> Here's an example of what I'm saying.
[snipped: Dan's example of sensitivity resulting from not all rows in
result set being materialized at once]
> allows the driver to fetch rows on-demand, the "or as the rows are
> retrieved" portion, thus I believe it's valid in JDBC to allow the
> resulting fetches to only return a single row:
>
> 3,55.0
>
> thus leading to a complete scrollable ResultSet that contains:
>
> 1, 10.0
> 8, 76.0
> 2, 45.0
> 3, 55.0
>
> In this case the insensitive ResultSet did see "other changes" that
> occurred after the execution.
I agree; this is a case where the JDBC definition of sensitivity is
more lax than SQL ("no significant changes"). I am still not
convinced this applies in the updateRow case, though, which I think is
Andreas' point here.
>
> Another valid implementation, which is what I think Derby does today, is
> to pre-fetch all the rows, leading to a ResultSet that "satisfy the
> query at [either] the time the query is executed". Namely
Yes, it is a valid implementation (even for SQL!), but in Derby as far
as I can tell the scrollable cursors materialize incrementally as rows
are accessed. I think this is good for large result set (gets first
rows cheaper). Andreas just found a bug in that area when holdability
is true (DERBY-1058).
Thanks,
Dag
>
> 1, 10.0
> 8, 76.0
> 2, 45.0
> 7, 95.0
> 3, 45.0
>
>
> Dan.
>
>
>
>
>
--
Dag H. Wanvik
Sun Microsystems, Database Technology Group (DBTG)
Haakon VII gt. 7b, N-7485 Trondheim, Norway
Tel: x43496/+47 73842196, Fax: +47 73842101
