Skip site navigation (1) Skip section navigation (2)

JTable and ResultSet TableModel with big resultset

From: "Stefano B(dot)" <stefano(dot)bonnin(at)comai(dot)to>
To: <pgsql-jdbc(at)postgresql(dot)org>
Subject: JTable and ResultSet TableModel with big resultset
Date: 2006-10-27 06:57:23
Message-ID: 004001c6f995$29cc8370$0501a8c0@comai04 (view raw, whole thread or download thread mbox)
Lists: pgsql-jdbc
Hi, I have a question about JTable and a ResultSet TableModel.

I have to develop a swing JTable application that gets the data from a ResultSetTableModel where the user can update the jtable data.
The problem is the following:

the JTable have to contain the whole data of the source database table. Currently I have defined a 


The problem is that when I execute the query the whole ResultSet is "downloaded" on the client side application (my jtable) and I could receive (with big resultsets) an "out of memory error"...

I have investigate about the possibility of load (in the client side) only a small subset of the resultset but with no luck. In the maling lists I see that the only way to load the resultset incrementally is to define a forward only resultset with autocommit off, and using setFetchSize(...). But this solution doesn't solve my problem because if the user scrolls the entire table, the whole resultset will be downloaded...

In my opinion, there is only one solution:

- create a small JTable "cache structure" and update the structure with "remote calls" to the server ...
in other words I have to define on the server side a "servlet environment" that queries the database, creates the resultset and gives to the jtable only the data subsets that it needs... (alternatively I could define an RMI client/server distribuited applications...)

This is my solution, somebody can help me?
Are there others solutions for my problem?

Thanks in advance,

pgsql-jdbc by date

Next:From: Dave CramerDate: 2006-10-27 11:33:31
Subject: Re: Applet problems
Previous:From: Morgan KitaDate: 2006-10-27 03:04:36
Subject: Applet problems

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group