Обсуждение: NullPointerException when calling ResultSet.absolute(int)
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 :-(
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
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
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
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
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
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
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
> > 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
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