Why does it balk when trying to reference a single field more than once? 1. ResultSet students = s.executeQuery("Select..."); students.next(); String f = students.getString(1); String first = students.getString(1); // error 2. Are you able to use the different scrolling options with the JDBC-ODBC bridge? Every time I tried I got a big fat exception. 3. What's up with only having one ResultSet open? Does anyone know of a plausible driver to use with Access? Why doesn't Sun ship a free workable driver ? That would make java much more friendly and appealling. It would also create something of a standard, instead of having to deal with JDBC implementation nuances. Questions, questions, questions...
1. I'm not sure why that happens, but why would you want to reference a field more than once? Also, instead of using column numbers, a more friendly way to get data is to use the column names: rs.getString("column_name"); 2. I don't believe ResultSets are scrollable with this driver. 3. You can only have one result set open? Really? Hmm... I didn't know that. For a small to medium sized application the JDBC-ODBC driver will do fine, though its performance is limited. And to address your last point, JDBC actually makes it very very easy to access a database.
Please make sure that you have more than one rows returned in the ResultSet ....
1. ResultSet students = s.executeQuery("Select..."); students.next(); String f = students.getString(1); String first = students.getString(1); // error
I've used getString(...) on the same column for the same row, it worked fine for me... so I guess the problem is either with the Driver or the number of rows returned... One more thing... I've found that (using Oracle's Driver), Suppose, you open a resultset. Before reading all the rows from it, you received another resultset from the same connection, and did something... The first resultset will be lost [ April 02, 2002: Message edited by: Wahid Sadik ]
Why doesn't Sun ship a free workable driver ? That would make java much more friendly and appealling. It would also create something of a standard, instead of having to deal with JDBC implementation nuances.
If this were an possibility, then you can be rest assured that Sun would have attempted this. Unfortunately, all databases work differently. They store information differently, they access information differently, they all have different limitations, etc., etc., etc.,... So it is not possible for Sun to create this universal driver you ask for. So what they did was create a bridge to allow the jdbc to relay the java instructions via native code to the databases existing ODBC drivers. The great thing about this that no matter which database you are using in java, all the code is the same. The downside is that all databases have limitations. If the existing ODBC driver on the user's machine does not have the ability to do something that you've asked it to do through java, then it throws an exception. So I guess what I'm saying is that the short comings of the JDBC:ODBC driver comes from 1. The limitation of the Database (MS Access is very limited) 2. The features supported by the driver. Not all JDBC methods are supported by the JDBC drivers. The short comings of the JDBC:ODBC bridge is due to the short comings of the ODBC driver, not JDBC. Also, make sure that your computer has the latest ODBC drivers to ensure that you have most capabilities and implementations possible for your driver. So by choosing the MS Access database with the JDBC:ODBC bridge, you have created a "worst case scenerio" for yourself. To make your life a little easier, make sure that you go to the Microsoft website and download the latest ODBC (Jet?) drivers for MSAccess. Jamie