Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Chris Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Serializing a ResultSet

Status
Not open for further replies.

MartinF

Technical User
Sep 19, 2000
143
FR
Hi,

I am new to Java and am trying to write a client/server app to remotley query a database. I need to send a ResultSet object returned from an SQL statement through an output stream into the client program, however i get an error message in the client program saying that the ResultSet is not serializable. How can i make it serializable?

Thanks in advance
 
The resultset only has a reference to the data. You could, however, hold all the data that was returned in a holder, and serialize that (make sure your holder implements Serializable), or, which is more common, an ArrayList/Vector of HashMaps/Hashtables containing all the results.
 
Hi, daniel135,

Thanks for your response, so basically, the simple solution for me would be to populate a vector with my ResultSet, and send that vector through the output stream.

What my client/server app is trying to do is provide remote access to a database that is stored on a central server by sending queries to the server program which then in turn returns the resultset. Is using sockets and streams the standard way of doing this, or is there another preferred method? i have read about some people using RMI, how exactly does this work?

Thanks again
 
We use Oracle here at work, and it's a rather simple process of registering the Driver and making a Connection.

It's a much more elegant way than Serializing a query result (especially when you don't need everything that is returned!). Try finding an online tutorial for your conditions -- Google being your best friend when it comes to tech info. Good luck!
 
The problem i am faced with here is that the back-end database is MS Access (dont ask me why) and it is not practical to connect to it directly over the WAN from the client App's due to the overheads it places on it, so this is why i am using the server app to do all the database processing.

Thanks again
 
The 'standard' approach would indeed be to connect directly from the client machine to the Access mdb using an ODBC connection set up on the client machine, and then using the jdbc:eek:dbc bridge.
Depending on what exactly you're doing, you may find that that works just as well as what you're attempting, because the ODBC drivers are reasonably well written.

If you're sure you need the kind of functionality you're going for, then I would say stick with your current strategy.
The idea of putting your resultset into a vector and then serializing that might not do it immediately becase serializing the vector might still fail when the objects inside aren't serialisable. But something like it should still work: loop through the resultset and copy each column of each row into a vector (or an array for that matter) and then you should have all the data in a serializable object.

Using RMI would be similar - it would require that the objects you pass about are serializable - put probably a lot simpler to program. In this case, your next step might be to go to and click on the RMI link.
 
Hi ChrisCarroll,

If i understand you correctly:
My experience of an MS Access database being run over a WAN is when the Access database is physically opened from a remote computer using MS Access itself, and consequently slowing the network down as a result and the database itself running very slowly. So what you are saying is that the jdbc:eek:dbc bridge can open the MS Access database quite efficiently over a WAN without incurring these overhead and speed issues. If this is the case, then i think this would be a better option for me to use. The functionality that i require of the client App is to be able to update records directly as well as run update queries to update batches of records at a time.

Thanks again for the input
 
I am saying it is at least worth trying.
It is true though that if you're running queries on large tables, then the odbc route may turn out just the same as the native access route.
However, for doing updates, so long as the records to be updated can be identified on their primary key, or at least on fields that are indexed, then you should be able to run it middlingly well over a Wan.

Alternatively:



both go for the same idea of copying your resultset into a vector by looping through the resultset.
 
Thanks again,

I think what i need to do now, is experiment with the different options to see which one works best for me.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top