Thread: NullPointerException when calling ResultSet.absolute(int)

NullPointerException when calling ResultSet.absolute(int)

From
Clemens Eisserer
Date:
Hi there!

I've installed PostgreSQL-7.4 on my system and I am really impressed
about the features and stability PostgreSQL provides. Its an excellent
piece of software!

However I've written a Swing-Table which displays data directly from a
ResultSet, and this works great if I select all rows, but when doing a
more specific search I get a NullPointerException:


Exception in thread "AWT-EventQueue-0" java.lang.NullPointerException
    at org.postgresql.jdbc2.AbstractJdbc2ResultSet.absolute(AbstractJdbc2ResultSet.java:184)
    at CATableModel.getValueAt(CATableModel.java:88)
    at javax.swing.JTable.getValueAt(JTable.java:1852)

Any ideas what could be the cause?

Thank you in advance, lg Clemens

btw. is there a more intelligent way to find out how many lines have
been selected than starting two queries where the one query just
queries the row-count?
I did not find any better solution, but for complex queries this is
really inefficient :-(

Re: NullPointerException when calling ResultSet.absolute(int)

From
Clemens Eisserer
Date:
Please ignore my first post, it was a very childish mistake in my code
of course ;-)
A local variable made a member-variable invisible and so I closed the
resultset which I wanted to use later ;-)

Sorry for generating traffic and thanks again for PostgreSQL, lg Clemens

Re: NullPointerException when calling ResultSet.absolute(int)

From
Oliver Jowett
Date:
Clemens Eisserer wrote:

> Exception in thread "AWT-EventQueue-0" java.lang.NullPointerException
>     at org.postgresql.jdbc2.AbstractJdbc2ResultSet.absolute(AbstractJdbc2ResultSet.java:184)
>     at CATableModel.getValueAt(CATableModel.java:88)
>     at javax.swing.JTable.getValueAt(JTable.java:1852)

From your later email this was because the ResultSet was closed. FWIW,
more recent drivers should throw an appropriate SQLException in this
case, instead of NPE.

> btw. is there a more intelligent way to find out how many lines have
> been selected than starting two queries where the one query just
> queries the row-count?
> I did not find any better solution, but for complex queries this is
> really inefficient :-(

Either you can use two queries, or use a scrollable ResultSet and call
ResultSet.last() / ResultSet.getRow(). The second approach causes the
entire ResultSet to be loaded into the Java heap, though, so it's not so
good for large results.

-O

Re: NullPointerException when calling ResultSet.absolute(int)

From
Clemens Eisserer
Date:
Hello Oliver and thanks a lot for answering,

> Either you can use two queries, or use a scrollable ResultSet and call
> ResultSet.last() / ResultSet.getRow(). The second approach causes the
> entire ResultSet to be loaded into the Java heap, though, so it's not so
> good for large results.
Currently I use the last()/getRow approach but as you confirmed this
approach does exactly what I don't want - to transfer the whole
selection between server and client.
Isn't there a workarround for this, maybe setting the fetch-size
(default set to 0)?

Thx, lg Clemens

Re: NullPointerException when calling ResultSet.absolute(int)

From
Oliver Jowett
Date:
Clemens Eisserer wrote:
> Hello Oliver and thanks a lot for answering,
>
>
>>Either you can use two queries, or use a scrollable ResultSet and call
>>ResultSet.last() / ResultSet.getRow(). The second approach causes the
>>entire ResultSet to be loaded into the Java heap, though, so it's not so
>>good for large results.
>
> Currently I use the last()/getRow approach but as you confirmed this
> approach does exactly what I don't want - to transfer the whole
> selection between server and client.
> Isn't there a workarround for this, maybe setting the fetch-size
> (default set to 0)?

Not with the current driver -- using a scrollable resultset disables use
of cursors, so the fetchsize is ignored.

-O

Re: NullPointerException when calling ResultSet.absolute(int)

From
Clemens Eisserer
Date:
Relly last question:

Sorry, I still don't get the whole thing :-(
Does that mean that the whole data is fetched from the server as soon
as I use scrollable result-sets?

Sorry for nerving and thanks for your patience, lg Clemens

Re: NullPointerException when calling

From
Mark Lewis
Date:
Yes.

On Tue, 2005-08-30 at 19:11 +0200, Clemens Eisserer wrote:
> Relly last question:
>
> Sorry, I still don't get the whole thing :-(
> Does that mean that the whole data is fetched from the server as soon
> as I use scrollable result-sets?
>
> Sorry for nerving and thanks for your patience, lg Clemens
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Have you searched our list archives?
>
>                http://archives.postgresql.org


Re: NullPointerException when calling ResultSet.absolute(int)

From
Oliver Jowett
Date:
Clemens Eisserer wrote:

> Does that mean that the whole data is fetched from the server as soon
> as I use scrollable result-sets?

That's right.

-O

Re: NullPointerException when calling ResultSet.absolute(int)

From
Clemens Eisserer
Date:
> > Does that mean that the whole data is fetched from the server as soon
> > as I use scrollable result-sets?
>
> That's right.

Hmm sad ... so I'll implement it with the last()->getRow technique if
it does not make any difference.
I wonder how hard this would be to implement, is it more than just
caching the already fetched rows - and how much does postgresql's
native protocol has support for this task?

Where can I get the current jdbc-sourcecode?

Thank you in advance, lg Clemens

Re: NullPointerException when calling ResultSet.absolute(int)

From
Kris Jurka
Date:

On Wed, 31 Aug 2005, Clemens Eisserer wrote:

>>> Does that mean that the whole data is fetched from the server as soon
>>> as I use scrollable result-sets?
>>
> I wonder how hard this would be to implement, is it more than just
> caching the already fetched rows - and how much does postgresql's
> native protocol has support for this task?

The frontend-backend protocol only supports fetching forward in a cursor
(portal).  To scroll a resultset based on a cursor you would have to use
direct SQL manipulation of the cursor MOVE/FETCH.  Someone tried this
awhile ago and came close to a working solution.  The driver source has
changed significantly since then and in a direction that makes this a
tougher thing to do...

http://archives.postgresql.org/pgsql-jdbc/2004-05/threads.php#00164


> Where can I get the current jdbc-sourcecode?

http://jdbc.postgresql.org/development/cvs.html

Kris Jurka