> i [sic] am trying to build an app that displays data from multiple
> tables in a single Derby database. the tables will be displayed in
> two different JTables with two different TableModels displayed on the
> same frame. Each TableModels will get their data from a JDBCRowSet
> object. My question is, should each TableModel have it's [sic] own
> JDBCRowSet instance; which seems the most straight-forward, but
What is the package in which 'JDBCRowSet' resides? The only similarly-named
API type I can find is
<http://java.sun.com/javase/6/docs/api/javax/sql/rowset/JdbcRowSet.html>
but that's not what you said. What is the class you're discussing?
If it is JdbcRowSet, that does not have the ability to be a disconnected
RowSet. (Read the Javadocs.) And you need to be more careful about spelling.
Case counts!
> requires multiple connections--or is there a better way-- to somehow
> use one connection and retrieve multiple result sets?
If you reuse a RowSet, or any ResultSet,
> A ResultSet object is automatically closed when the Statement object
> that generated it is closed, re-executed, or used to retrieve the
> next result from a sequence of multiple results.
<http://java.sun.com/javase/6/docs/api/java/sql/ResultSet.html>
This presumably will not affect disconnected RowSets, but the fact remains
that re-using a RowSet for multiple models will be very difficult. Each time
you load it for one TableModel, you somehow would have to get the other
TableModel not to use it, and vice versa. Seems complicated.

Signature
Lew
The word "I" in English is capitalized. Case counts.
mdR - 30 Jan 2008 13:40 GMT
> > i [sic] am trying to build an app that displays data from multiple
> > tables in a single Derby database. the tables will be displayed in
[quoted text clipped - 29 lines]
> Lew
> The word "I" in English is capitalized. Case counts.
Thanks again for the reply... (it was late and I just wanted to get
some answers overnight for today--got lazy on the caps)
I kind of thought re-using a RowSet would be trouble and difficult to
manage. So that answers that.
Yes, I meant JdbcRowSet, and I'm not sure that I want a disconnected
RowSet. It's going to be a fairly large database. It probably won't
be able to load all in memory. Wouldn't I want to use JdbcRowSet?
-mark
Lew - 30 Jan 2008 14:56 GMT
> Yes, I meant JdbcRowSet, and I'm not sure that I want a disconnected
> RowSet. It's going to be a fairly large database. It probably won't
> be able to load all in memory. Wouldn't I want to use JdbcRowSet?
I don't know. I've been writing Java JDBC code for nine years and never once
used JdbcRowSet. What are its advantages over regular RowSet or ResultSet?

Signature
Lew
mdR - 30 Jan 2008 22:13 GMT
> > Yes, I meant JdbcRowSet, and I'm not sure that I want a disconnected
> > RowSet. It's going to be a fairly large database. It probably won't
[quoted text clipped - 5 lines]
> --
> Lew
hmm... I see your point. After a little closer reading on the RowSet
and JdbcRowSet API, it appears the use of a JdbcRowSet is not needed.
I'm coming from JBuilder where all the database stuff was "behind the
curtains" and I didn't have to do as much. They had various DB and
GUI beans for different "stores" of data. Then in the latest release
of JBuilder they dropped their database swing components and support,
so now I've got to back up and learn all the stuff under the hood.
Which, I guess, is a good thing. Just running into some confusion,
which you guys are helping straighten out :) Actually it's becoming
pretty fun!
What happens on extremely large databases? Say, a table that has
50,000 rows and each row has about 16 columns with each column being
char(30). Or is that not that large?
-mark
> ok, i think i'm getting a handle on the whole MVC thing and how i
> should be constructing my db application. But i am still confused on
[quoted text clipped - 8 lines]
> requires multiple connections--or is there a better way-- to somehow
> use one connection and retrieve multiple result sets?
No, connections are not _that_ expensive. In Derby
the connection is simply a Java thread with an associated socket. It
doesn't grab huge chunks of memory so it does not add much to the
footprint either.
Note that in Derby obtaining the first connection (with the create=true
property) could take some time, because the whole database gets
created. But getting the next connection to that database will be very
quick (as will getting a connection to an existing database).
And you should use PreparedStatements for anything where performance is
important. This is true for most databases, but especially for Derby
which compiles SQL to java byte code which is a rather heavy
process.
> btw--this is going to be a multi-user client/server app.

Signature
dt
Questions about Derby/Java DB? Please visit
http://db.apache.org/derby/derby_mail.html
mdR - 30 Jan 2008 13:42 GMT
On Jan 30, 2:41 am, Dyreatn...@sun.com wrote:
> > ok, i think i'm getting a handle on the whole MVC thing and how i
> > should be constructing my db application. But i am still confused on
[quoted text clipped - 30 lines]
>
> Questions about Derby/Java DB? Please visithttp://db.apache.org/derby/derby_mail.html
Great! Above combined with Lews comments puts me on the right
track.
And yes, I plan on using PreparedStatements.
Thanks again.
-mark