Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.java.programmer > #31557

Re: JDBC: scroll cursor "broken" after fetch absolute beyond end?

From Marcel Mueller <news.5.maazl@spamgourmet.org>
Newsgroups comp.lang.java.programmer
Subject Re: JDBC: scroll cursor "broken" after fetch absolute beyond end?
Date 2015-04-13 01:34 +0200
Organization MB-NET.NET for Open-News-Network e.V.
Message-ID <mgevde$jvt$1@gwaiyur.mb-net.net> (permalink)
References <slrnmifbpd.uoi.avl@login.logic.tuwien.ac.at> <mg8o33$oud$1@gwaiyur.mb-net.net> <slrnmilrbp.uoi.avl@login.logic.tuwien.ac.at>

Show all headers | View raw


On 13.04.15 00.10, Andreas Leitgeb wrote:
>> Maybe you can use beforeFirst() as work around. It resets the cursor to
>> its initial state.
>
> Tried it, but unfortuately it didn't help.  Even after rc.beforeFirst(),
> the rc.absolute(1) still returned false.
> Btw.,  ( pos==1 ? rc.first() : rc.absolute(pos) ) also didn't help.

I thought more of beforeFirst() followed by the usual read access with 
next().


>>> PS: whether attempting an rs.absolute(100) is the most elegant approach
>>>     to checking for "at least 100 rows" is not so much the question here,
>> Indeed, it is more likely a very inefficient way.
>
> While I originally didn't want to focus on that, I've changed my mind:
>
> Assuming that the number of results might just as well be >10000 and if
> all I want to know is: "is it >= 100 ?", then just positioning it to that row
> didn't appear like "very inefficient" to me -- if only it worked as promised.

Well, the most efficient way is to read the first 100 rows if you need 
them anyway. If you do not need them, you would not concern about 
absolute(1).
Even if you only need the first 10 rows it is more straight forward to 
read them and then jump to row 100 to see whether there are more than 100.

All of this won't run into your problem and will be happy with a forward 
only cursor. A forward cursor will cause less locking or less snapshot 
memory respectively in case of optimistic locking.


> Apparently, the only other way of getting that information is to position on
> last() and check the rs.getRow().  But this might mean that the DB has to
> search it all through...

Indeed, bad idea.


Marcel

Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

JDBC: scroll cursor "broken" after fetch absolute beyond end? Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> - 2015-04-10 11:07 +0000
  Re: JDBC: scroll cursor "broken" after fetch absolute beyond end? Marcel Mueller <news.5.maazl@spamgourmet.org> - 2015-04-10 16:52 +0200
    Re: JDBC: scroll cursor "broken" after fetch absolute beyond end? Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> - 2015-04-12 22:10 +0000
      Re: JDBC: scroll cursor "broken" after fetch absolute beyond end? Martin Gregorie <martin@address-in-sig.invalid> - 2015-04-12 23:17 +0000
      Re: JDBC: scroll cursor "broken" after fetch absolute beyond end? Marcel Mueller <news.5.maazl@spamgourmet.org> - 2015-04-13 01:34 +0200
      Re: JDBC: scroll cursor "broken" after fetch absolute beyond end? Andreas Leitgeb <avl@auth.logic.tuwien.ac.at> - 2015-07-20 22:26 +0000
  Re: JDBC: scroll cursor "broken" after fetch absolute beyond end? Arne Vajhøj <arne@vajhoej.dk> - 2015-04-12 21:51 -0400

csiph-web