[ 10-99 ]

> Hi!!
>
> At the moment I have a database in MS Access which is on the server. I have
> developed a GUI (Applet) with which one can make selections that he needs.
> Now what I need is to query the database based on the selections made by the
> user. I thought JDBC would the best way. Do you think, I should go ahead and
> use JDBC or use some other method? IF so could you gimme some suggestions.
>
> Hari

As I said in my web page, there are two ways to use JDBC in your applet:
directly or indirectly.   By using it "directly", I mean that you can
use JDBC just as if your database resided on a local machine, and need
virtually no extra code to make it work over the internet.   Obviously,
to be able to use it directly is a more convenient, since all you
need to learn is JDBC.   You don't need to learn about servlets or CGI,
for example.

The only ways that I know of that you can use JDBC directly are these:

1. RmiJDBC    
2. a commercial database server, like dbAnywhere or SQL Server, combined with
a JDBC driver.
3. A shareware or freeware database server that comes with a JDBC driver.
(I don't know if there is such a thing, and it's been a long time since I've
researched this.  It's possible there is one, now.)
4. Using the JDBC-ODBC  bridge as your driver, and running your applet
on a limited, known set of machines that you are willing to configure one
by one.

[ Note, when I say "database server", I mean a database program that accepts
socket connections, like a web server or ftp server, or dbAnywhere.]

If you use JDBC indirectly, this means you can't make JDBC calls in your
applet code.   An example would be CGI or servlets:   you would need to
send a message to your CGI program or servlet to query the database, and
the servlet would do the actual querying of the database (using JDBC).
Then the servlet would return the results back to your applet in the form of
Strings(as I understand it).   You'd need to parse these strings to obtain
the results of your query.

I don't have a sample of using servlets for database querying, but I'm      
sure there are some out there.   To use servlets, you need a web server
that is capable of running servlets.

The indirect ways of using JDBC are these:

1.  CGI, or servlets.
2.  Write your own database server, using a socket server (as I describe
in my web page).

Which solution you choose depends partly on what options are available
to you.  Eg., servlets and CGI are out if your web server can't run them.

Some considerations are these:

1 - Does the database need to accessible by a limited number of people
that use a particular, known set of machines, or does it need to be accessible
by anyone from any machine with a browser?
2 - If you were running a server of some kind(besides the web server)
could you leave it running all the time?

If the answer to "1" is "anyone with a browser", then you could not use the   
JDBC-ODBC bridge *directly* as your JDBC driver.   That's because you would
have to register your database in the ODBC control panel on *every* machine
that might run your applet.

Note, you could still use the JDBC-ODBC bridge indirectly.   For example, your
servlet or CGI program could use the JDBC-ODBC bridge to query Access.
RmiJDBC also allows you to use the bridge.

If the answer to "2" is "can't run it all the time", and you needed to have
continuous access to your database, then that would rule out using your
own database server, as well as rule out RmiJDBC.   It might even rule out
a commercial database server(since a user might come along and shut down the
machine).   Your options in that case would be servlets or CGI.

I don't know if all of this is helpful, but it just illustrates that
the method for using JDBC depends a lot on what your particular situation
is.

If you are doing this for a class project, then you can probably just
run your database server (or RmiJDBC server) when you need it.   In that
case, the simplest solution would be RmiJDBC.   RmiJDBC isn't really a    
"database server", but a "Remote Method Invocation server", but either way,
it exits when a user logs out of windows NT, or reboots.   If that's not
a problem, I'd suggest looking into it.

--Kurt