JDBC & ODBC

[ceaton]

I am creating an application in with Java applets that reside on HTML pages. The applets(11)<br>
gather contain the information the user wants to use in the SQL and calculations. Now, I have .dbf tables with the information that is needed to perform the SQL and calculations.The problem is that this application is going to be installed on the users machine from a CD-ROM along with the data files. I have read about the JDBC-ODBC bridge<br>
and I was told about how it &quot;might&quot; work. I need to know for sure. I can't have the user trying to configure their ODBC from the Control Panel. I need this to happen without any user intervention. If there are any suggestions on how to accomplish this please let me know.<br>
<br>
Thanks,<br>
<p> Courtney<br><a href=mailto: ceaton@lrp.com> ceaton@lrp.com</a><br><a href= > </a><br>

 

[pmailman]

We faced a similar problem in our Java project. The solution we chose was to use a middleware server, Symantec dbANYWHERE. (I don't think dbANYWHERE is the only game in town for this; we went with it because it is bundled with Visual Cafe, which we were using for our IDE.) dbANYWHERE sits on the Web server machine. You reference it from your applet using a JDBC URL. No additional software needs to be installed or configured on the client. (It does require an additional archive file for the interface, but that resides on the server, as any supporting JAR file would.) The trick that saves your poor end-users the agony of configuring their client is that the configuration happens on a single, central machine (i.e. the Web/dbANYWHERE server) instead of at the client.<br>
<br>
In this case, the database linking software that you install/configure on the server could be either direct JDBC or JDBC/ODBC depending upon what is available or convenient for the specific database engine you're linking to.<br>
<br>
Depending upon your deployment situation, there may be another alternative. If your situation is intranet rather than Internet, you may be able to use a JDBC/ODBC link, create the ODBC datasource on the server, and make the datasource available to your clients through the file system (e.g. through Microsoft Networking if this is a pure Windows situation, or NFS or Novell or whatever). Or you may be able to install a copy of the datasource file on the client.<br>
<br>
If you did this, I think you'd still have to install a JDBC driver specific to your database engine on each client machine.<br>
<br>
If you're in a UNIX environment rather than Microsoft, I'm not sure how to go.<br>
<br>

 

[ceaton]

Thanks for your reply, however I don't have any of those situations. I do not have a server in which the data files reside. This application is going to be going onto a CDROM in which the user installs the program including the data files.<br>
<br>
Thanks anyway,<br>
<br>
Courtney

 

[pmailman]

If this is strictly local to one machine, that may simplify things.<br>
<br>
I'm not familiar with the .dbf file type. What kind of database does that represent? Whatever it is, your next stop is to determine what must or may be installed on the machine to support that database. Your best bet ought to be the documentation for or otherwise the vendor of the database engine. There may be third-party vendors as well (e.g. Intersolv) who offer drivers for this kind of database<br>
<br>
If you can find native JDBC driver for this database, that's probably the best way to go. Since not all vendors support JDBC directly, but many support ODBC, a good fallback is an ODBC driver with a JDBC-ODBC bridge. Similar to what I said in my earlier message concerning intranet installation, if you're installing from a CD-ROM, I think you should be able to prepare ahead of time an ODBC data source file and install _it_ off the CD-ROM too.<br>
<br>
Though I've never done this, I'll give you dollars to doughnuts it can be done this way. I know I've installed several database-related products on my development system that have included demos, and as part of their installation process they created ODBC datasources for me (no additional ODBC configuration required by me), which were then used in the demos.<br>
<br>
So... It _can_ be done; the trick is determining the details of how.<br>
<br>
<br>