JDBC FAQ - Programming Databases with Java
Thornton Prime
==========================================================================
JDBC Frequently Asked Questions
==========================================================================
CONTENTS
0 About this FAQ
1 General Questions about JDBC
1.1 What is JDBC?
1.2 Where can I get JDBC?
1.3 How do I install JDBC?
1.4 What alternatives to JDBC are available?
1.5 Where do I start?
2 JDBC Drivers and Programming Tools
2.1 What are the different categories of drivers?
2.3 What JDBC drivers are available?
2.2 What are the advantages and disadvantages of middleware?
2.3 Where can I find native drivers for MS Access?
2.4 What Java programming tools support JDBC?
2.5 Can I use vendor X's JDBC solution with vendor Y's IDE?
2.6 What is the fastest type of JDBC driver?
2.7 How can I write my own JDBC driver?
3 The JDBC-ODBC Bridge
3.1 What is the JDBC-ODBC bridge?
3.2 What are the performance implications of using the JDBC-ODBC
Bridge?
3.3 How do I configure ODBC for the JDBC-ODBC bridge?
4 Applets and JDBC
4.1 Why doesn't my applet using JDBC work?
4.2 What's wrong with using JDBC in applets?
4.3 What's wrong with using the JDBC-ODBC Bridge with Java applets?
4.4 How can I protect my database if someone can de-compiles my Java
applet and steal my database login information?
5 Programming JDBC
5.1 How can I get a count of a ResultSet?
5.2 Why is there no method to step backwards in ResultSets? Why is
there a next() but no prev()?
--- Glossary
+++ Resources
==========================================================================
0 : About this FAQ
This FAQ (Frequently Asked Question list) has been compiled by me,
Thornton Prime, to help answer some of the common questions regarding
the use of JDBC. I in know way guarantee its accuracy and assume no
liability for any part of it.
If you have an addition or correction, please e-mail me at
th...@primenet.com. I would be happy to give you credit.
This FAQ is available at http://www.yoyoweb.com/Javanese/JDBC/FAQ.txt.
==========================================================================
1 : General Questions about JDBC
1.1 : What is JDBC?
JDBC stands for Java Database Connectivity. It is an application
programming interface (API) for Java for connecting to and using
databases. The API provides access to a driver manager and a driver
interface.
The JDBC API, in conjunction with JDBC drivers, provides a layer of
abstraction so that Java programmers can program to a single database
API for all databases with capable JDBC drivers, rather than each
programmer having to learn a different API for different databases.
JDBC is not a client server protocol (nor does it specify one) for
accessing database information on remote servers, though individual
database drivers may act as clients to database servers. (For more on
this see the description of different driver types in 2.1.) Every
database server has its own network protocol. Some databases do not
use networking at all, but are based entirely on file reads and
writes. Communication with the database, whether by network or through
files, is hidden from the programmer and implemented entirely in the
driver. This is the power of JDBC. You don't worry about how to get
read the database, you only concern yourself with the data you want
and the SQL you need to manipulate it.
JDBC does not have any security features, though it does take
advantage of Java security and can use database security with a
capable driver.
JDBC does not really specify what SQL you can use, it simply passes
the SQL on to the driver and lets the driver either pass it on
directly to the database, or parse the SQL itself.
1.2 : Where can I get JDBC?
JDBC is now part of the core Java API as defined by JavaSoft. The
latest version of the Java API includes the latest version of JDBC as
the java.sql package.
Because JDBC is not included in the versions of Java before JDK 1.1,
browsers which do not yet support the Java 1.1 API (including Netscape
3.0 and Internet Explorer 3.0) cannot load the JDBC API as applets.
Some JDBC driver vendors offer their own solution to this problem by
offering their own version of the JDBC API recompiled under a
different name.
1.3 : How do I install JDBC?
It is installed along with JDK 1.1.x. Any environment which supports
the full Java 1.1 API should include JDBC.
JavaSoft also offers a download of an older version of JDBC that works
with JDK 1.0.2. Since the primary reason to use JDK 1.0.2 would be for
browser compatibility, and since browsers cannot load this package
over the network (see 4.1 for an explanation of this), developers who
wish to use JDBC in a 1.0.2-compatible environment should consult
their JDBC driver documentation for instructions and support.
1.4 : What alternatives to JDBC are available?
Considering the amount of support in the Java community for JDBC, it
is not advisable to seek alternative solutions. Nevertheless, there
are some alternatives to JDBC.
Microsoft's Java VM supports access to Microsoft COM (Component
Object Model) objects, including DAO (Data Access Objects) and RDO
(Remote Data Objects). Instructions for using COM objects with Java
are included in Visual J++ and on Microsoft's website. Microsoft has
included a JDBC interface to ADO in their SDK for Java 2.0. Both of
these ONLY work with Microsoft's Java VM for Windows 95 and Windows NT
because they depend on native Win32 code and Microsoft's native code
model.
Other alternative database connectivity solutions can be found at the
Gamelan website (http://www.gamelan.com).
Finally, you can write your application in such a way that would not
require database connectivity on your clients. Typically, this
involves a 3-tiered model with client applications or applets
connecting to a server which handles most of the program logic. The
server in turn connects to the database, either using JDBC or some
other connectivity solution.
1.5 : Where do I start?
If you do not already know SQL, learn it.
Next, get the JDBC API (included in JDK 1.1 and above) and a
compatible JDBC driver.
Sun has included a sample JDBC application, called SimpleSelect with
the JDBC distribution. It demonstrate retrieving a simple data set
from a database using the JDBC-ODBC Bridge.
There are several books on JDBC also. See the book list below.
==========================================================================
2 : JDBC Drivers and Programming Tools
2.1 : What are the different categories of drivers?
JavaSoft has broken categorized JDBC drivers into four basic groups.
They are:
1 - JDBC-ODBC Bridge Driver
The JDBC-ODBC Bridge driver translates JDBC calls into ODBC
calls on the client machine. This involves native method calls.
Presumably, the Microsoft JDBC-ADO driver would also fall into
this category as it also maps JDBC to another database API used
to access a broad variety of databases.
2 - Native-API Partly-Java Driver
This type of driver translates JDBC calls to their native
database API on the client machine using the vendor's native
API. They, like the Bridge, require native method calls.
3 - Net Protocol All-Java Driver
This type of driver uses an all-Java driver, deployed on the
client, to speak to a server, which translates the calls into
native API database calls. This category requires some
intermediary service (typically called middleware).
4 - Native Protocol All-Java Driver
This type of driver, written entirely in Java, speaks directly
to the database server using the database server's native
network protocol.
I have made a graphical representation for the WWW
(http://www.yoyoweb.com/Javanese/JDBC/DriverTypes.html).
For more information, visit JavaSoft's JDBC Driver Page
(http://splash.javasoft.com/jdbc/jdbc.drivers.html).
2.2 : What JDBC drivers are available?
JavaSoft has a list of most JDBC drivers at their website.
(http://splash.javasoft.com/jdbc/jdbc.drivers.html).
2.3 : What are the advantages of middleware?
Middleware servers open up a wide range of databases to JDBC without
requiring customized software installation on client machines. Because
the middleware JDBC drivers themselves are "pure Java" they can be
distributed at runtime as part of an untrusted applet.
Middleware servers can also serve data from database engines that
normally have no server. Many desktop databases, including Microsoft
Access, Paradox, and dBASE do not include a database server, only an
engine for reading local databases. A middleware server can act as a
server for these types of databases.
Middleware servers can translate calls to access a server that would
normally not be accessible to Java. For example, a middleware server
could translate requests between a JDBC applet which speaks TCP/IP to
packets for a server that only spoke IPX.
Many middleware servers can open paths to a number of different
databases of different types simultaneously. If your data is stored in
a variety of different databases, this may eliminate the need for
multiple drivers in your client applications.
Middleware servers can add a layer of security, requiring additional
authentication and validation of client requests. This might be
especially important if your database has limited security features.
Furthermore, they help mediate the requests from the client
connections, which could reduce server load and (since all requests to
the database server itself come from a single middleware server) avoid
connection limitations, license restrictions, and can reduce costs.
Middleware server may also aid in building scaleable servers by
distributing client load over several database servers. Furthermore,
it may reduce updates to the client applications (or applets) to
accommodate a changes in the database server.
2.2 : What are the disadvantages of middleware?
As with any system, the more layers that you introduce, the more
complicated management and development becomes. In addition to client
software and a database server, you have to worry about the state of
the middleware server. Debugging may be difficult if you are not sure
if a bug is in the client, the driver, the middleware, or the database
server.
There may be hidden costs to consider when buying a middleware server,
notably the hardware and administration time and energy it may
require.
Finally, middleware servers can increase your network traffic,
decrease performance, and affect the scalability of your client-server
application because all requests need to be processed by the
middleware server before being forwarded to your database server.
This can be addressed with the correct network topology.
2.3 : Where can I find native drivers for MS Access?
Many people have been asking for "Pure Java" MS Access drivers. Apart
from using middleware (Type 3 drivers) or the Bridge, there are
currently no drivers for MS Access.
MS Access is a file-based database in a proprietary format. Firstly,
this means that access to the database itself is limited by access to
to the filesystem on which it resides. This means that in order to
write a pure Java driver for MS Access, you would need to
(a) open a socket to the file server and download the database file,
then upload the file after making changes, and
(b) be able to understand Microsoft's proprietary format after
retrieving the database file.
Both are theoretically possible (you could port SMB/CIFS to Java and
reverse engineer the Jet API), but practically impossible.
Furthermore, overcoming all other obstacles, because MS Access is file
based (there is not server handling connections) MS Access would still
be unsuitable for multi-user database writes. There is not a server
coordinating database reads and writes. One person will inadvertently
overwrite another's changes, or both will corrupt the database file.
Middleware is the only safe solution for multi-user access to an MS
Access database. The only other alternative is the JDBC-ODBC Bridge,
or some other native-code dependent implementation (like Microsoft's
JDBC-ADO bridge).
2.4 : What Java programming tools support JDBC?
JavaSoft has made JDBC part of the core API for JDK 1.1. Most Java
tool vendors have not only agreed to support JDBC, they are bound by
their licensing contract to support it within a reasonable amount of
time after the final release of JDK 1.1. While at least one tool
vendor (Microsoft) has argued that they reserve the right to choose
which class libraries they distribute with their product, they will
almost certainly support JDBC.
The JDBC core is written entirely in Java and thus should work in most
current IDEs in its present state. JavaSoft has provided source code
for the JDBC API to assist JDBC driver developers and programmers.
Microsoft provides support for JDK 1.1 in the MS SDK for Java 2.0
(currently in beta). Symantec has released version Cafe 1.8, which
fully supports JDK 1.1.2. There is a preview version of Visual Cafe
that supports JDK 1.1.2.
2.5 : Can I use vendor X's JDBC solution with vendor Y's IDE?
The JDBC driver manager, which is written entirely in Java, handles
loading and unloading drivers and interfacing requests with the
appropriate driver. It was JavaSoft's intention to make the use of a
specific JDBC driver as transparent as possible to the programmer and
user.
Any driver fully meeting the JDBC specification should work with any
IDE that is capable of supporting JDBC. On the other hand, most driver
developers do not release the source code for their drivers, so you
will be unable to debug the actual driver itself. Furthermore, even
with source, a driver which requires a native code interface will
require an IDE capable of debugging native code, if that is what you
need.
Apart from limitations with specific JDBC drivers, changing from one
JDBC driver to another requires only a few changes to your source code
or configuration file.
2.6 : What is the fastest type of JDBC driver?
JDBC driver performance will depend on a number of issues:
(a) the quality of the driver code,
(b) the size of the driver code,
(c) the database server and its load,
(d) network topology,
(e) the number of times your request is translated to a different
API.
In general, all things being equal, you can assume that the more your
request and response change hands, the slower it will be. This means
that Type 1 and Type 3 drivers will be slower than Type 2 drivers (the
database calls are make at least three translations versus two), and
Type 4 drivers are the fastest (only one translation).
Of course, like any assumption ... you should test it on your own
system. Most likely your network, your database server, or the type of
access your application requires, may prove this assumption to be
false. If you like, I will reprint a summary of your experience here.
Connect Software (http://www.connectsw.com) claims their Type 4 driver
is 30% - 60% faster than Type 3 or 1 drivers. I have verified this
claim on my system by comparing it to dbANYWHERE and the JDBC-ODBC
Bridge (it was actually twice as fast or faster sometimes, especially
with PreparedStatements).
2.7 : How can I write my own JDBC driver?
The JDBC API specifies interfaces which you implement to define your
driver.
I would recommend getting the source code to a good driver and
starting from there.
The book _Java Database Programming with JDBC_ (Patel & Moss, 1996)
includes source code for two JDBC drivers, a driver for simple text
databases, and a driver for DB2. (See the resources section below for
a link to the publisher's web site.)
==========================================================================
3 : The JDBC-ODBC Bridge
3.1 : What is the JDBC-ODBC bridge?
To speed up development and deployment of JDBC-compatible
applications, JavaSoft and Intersolv created a JDBC-ODBC bridge which
translates JDBC calls into ODBC. ODBC is Microsoft's Open Database
Connectivity standard which has been widely accepted for Windows-based
databases database clients. ODBC is also available on the Mac and some
UNIX platforms, though the Bridge is so far only available for Win32
and Solaris. With the Bridge, Java developers can begin applications
development with the hundreds of pre-existing ODBC drivers.
If you are considering using the JDBC-ODBC Bridge for applet
development, please read section 4.3 of this FAQ.
3.2 : What are the performance implications of using the JDBC-ODBC
Bridge?
The JDBC-ODBC Bridge depends on the cooperation of several different
components, many from different vendors, to get data from your
database to your Java code. These components include:
o The JDBC Driver Manager (from JavaSoft)
o The JDBC-ODBC Bridge Driver (from JavaSoft and InterSolv)
o The ODBC Driver Manager (from Microsoft)
o The ODBC Driver (hopefully from your database vendor, though
possibly from a third party)
o The Database (from your database vendor)
Some ODBC drivers may require their own set of dependent components to
span different network protocols or APIs.
Each of these layers requires translating your request for data into a
new, and possibly very different, format. Similarly, the response
returned from the database needs to be translated several times before
it reaches your Java code. Each translation introduces its own set of
limitations and possibly bugs, in addition to consuming memory and
computing power.
The JDBC-ODBC bridge is only as strong as the weakest of the links in
the chain that support it. The number of layers also make the
JDBC-ODBC bridge the worst of possible performers with respect to
speed and memory usage.
3.3 : How do I configure ODBC for the JDBC-ODBC bridge?
ODBC configuration depends on your operating system and ODBC version.
I have some instructions available for Windows machines at my website
(http://www.yoyoweb.com/Javanese/JDBC/ODBC.HowTo.html). If you have
instructions for UNIX or Mac, I would be happy to post them there
also.
==========================================================================
4 : Applets and JDBC
4.1 : Why doesn't my applet using JDBC work?
There are a number of reasons why applets may not work with JDBC.
Some of the most common are:
(If you are thinking about using the JDBC-ODBC Bridge with a Java
applet, please also read the next question and answer, 4.3.)
o The applet security model prevents untrusted applets from making
network connections to any host except the originating host. This
means that an untrusted applet using JDBC can only connect to a
database server (or middleware server) running on the same host that
the applet was downloaded from.
o The applet security model prevents an untrusted applet from
accessing local system resources, including ODBC configuration
information. Even with the correct native code libraries
pre-installed on the local machine, the JDBC-ODBC bridge requires
access to correctly-configured ODBC data source information stored
on the local machine. Some drivers (including many ODBC drivers) may
require that the database be installed on a local drive or a mounted
network resource, both of which are inaccessible to Java applets.
o The applet security model prevents loading untrusted native code
over the network. Specifically this means that drivers which require
native code libraries, like the JDBC-ODBC Bridge, cannot be loaded
into a browser from a web server. The native code libraries need to
be installed on the local machine before starting the browser.
o Not all Java VMs use the same native code interface. Notably,
Netscape and Microsoft do not use the same native code extensions as
Sun and JavaSoft. JavaSoft is planning to make their native code
interface part of the JDK 1.1 specification, so you will only need
to make sure people have the correct native code library for a
particular operating system. Until the interface is implemented in
all VMs, though, drivers which require native code (including the
JDBC-ODBC bridge) need native code libraries specific to the
particular Java VM.
o Some applet security models prohibit loading packages under the
java.* tree. This prohibits loading the java.sql.* package, required
by both the applet and driver, over a network. Either the java.sql.*
package would need to be installed locally before starting the Java
VM or browser, or both the applet and driver need to be compiled to
load the JDBC API classes from a different package name.
Symantec's dbANYWHERE, for example, uses symjava.sql.*. Other
drivers use jdbc.*. This problem should be resolved when Java VM and
browser developers incorporate the new JDK 1.1 specifications (which
includes JDBC).
In general, for applet JDBC development, you should plan on using a
Net Protocol All-Java Driver (Type 3) or a Native Protocol All-Java
Driver (Type 4). Furthermore, until JDBC is integrated into browsers
and VMs, you will need to develop your applets using an alternative
package name for the JDBC library. That alternative package name will
need to match the name supplied by your driver vendor.
If you have followed all of the restrictions above to program your
applet and it still does not work, before posting your question to a
newsgroup (preferably comp.lang.java.databases), be sure you check
your applet works in the JDK appletviewer. appletviewer does not have
any of the security restrictions listed above when loading local
applets. Also, try to get a stack trace of any exception it may
throw.
4.2 : What's wrong with using JDBC in applets?
Nothing, but you should consider the alternatives.
Java applets have several restrictions, and are also the likely
target of reverse-engineering. (See section 4.4 for more on this.)
JDBC does not work consistently on all browsers yet (see 4.1 above).
While the JDBC API is small, JDBC drivers can be large (in some cases
100K - 500K), and will substantially increase the time it takes to
download and run your applet.
Finally, using JDBC in an applet means being able to connect to a
database server or a middleware server running on the same host as
your web server. Your ISP may not offer or allow this.
If your data can be formatted using HTML, and your requests can be
implemented in HTML forms, a CGI will in all likelihood be faster,
safer, and compatible with more web clients. If you prefer programming
in Java, consider Servlets (http://jserv.javasoft.com).
JDBC applets work great in intranets, or other limited distribution
environments, but may be problematic in general Internet distribution.
4.3 : What's wrong with using the JDBC-ODBC Bridge with Java applets?
The best reason is "because that's not what it's there for." The
JDBC-ODBC Bridge is a development and testing tool, not a production
quality driver.
Additionally, one should realize:
o The JDBC-ODBC Bridge will not work with untrusted applets because:
(a) The JDBC-ODBC Bridge driver uses native code (JdbcOdbc.dll or
JdbcOdbc.so on UNIX).
(b) ODBC drivers require native code. ODBC is an API developed
specifically for Windows, and most of the drivers are written in
C or C++ for Windows or Win32. While some drivers have been
ported to UNIX or Mac, their availability on other platforms is
sporadic at best.
(c) Using ODBC means reading local configuration settings. ODBC DSN
(data source names) identify the different ODBC databases
available on a machine, and the drivers they require. DSNs must
be configured (in the ODBC control panel on Windows) before any
program can use a database through ODBC.
(d) Many (but not all) ODBC drivers need to get a local file handle
to perform their operations. This means that the database needs
to either be on a local drive, or on an accessible network file
server. This includes the ODBC drivers for Microsoft Access,
Lotus Approach, dBASE, Microsoft Excel, and the flat file ODBC
driver.
o ODBC is not available on all platforms. ODBC is a Microsoft product,
and must be licensed from Microsoft. Microsoft has versions of ODBC
for Windows, Windows 95, Windows NT, and Macintosh. The Windows
versions may work under OS/2. Other companies have ported ODBC
(under license) to a few UNIX platforms (including Solaris). There
is currently not port of ODBC for Linux (though, I'm sure, someone
out there is working on it).
ODBC is not part of any operating system and must be installed,
either separately, or as part of another product (like Microsoft
Office or MS SQL Server). It is widely available on Windows
machines, but is not included as part of the Windows 95 or Windows
NT installation (though it is installed if you install one of
Microsoft's Web Server products, which are included with Windows
NT).
o The JDBC-ODBC Bridge is not part of the standard Java distribution.
The JDBC-ODBC bridge is included in the JDK 1.1 for Windows NT and
Solaris. It is not included with Microsoft Internet Explorer or
Netscape.*
Like all classes not in the java.* tree, it is not considered "core"
API, and programmers can not assume that it is available (or
implemented) in all Java run-time environments.
(*Some UNIX versions of Netscape DO include the sun.jdbc.odbc.*
classes, but do not include the necessary corresponding JdbcOdbc.so.
Inclusion of these classes is obviously an oversight on the part of
the Netscape. They do not work without ODBC installed and without
the JdbcOdbc.so.)
o ODBC drivers cannot, like JDBC drivers, be distributed at run-time.
The ODBC installation and configuration procedure is platform
dependent and requires (on some machines) specific system
permissions.
o The JDBC-ODBC Bridge driver is not client-server. While the
JDBC-ODBC bridge may load an ODBC driver that does act as a client
to a database server, this depends entirely on the availability of a
capable ODBC driver, loaded and configured locally.
o The JDBC-ODBC Bridge is riddled with performance and capability
problems. In some cases this may be because the JDBC-ODBC Bridge
depends on flawed ODBC drivers, but in other cases they are simply
flaws in the JDBC-ODBC Bridge.
This includes problems opening multiple, concurrent Connections, and
opening multiple, simultaneous Statements in the same Connection.
The JDBC-ODBC Bridge is "thread safe," but only because all the
methods are synchronized. The JDBC-ODBC Bridge has no way of knowing
if the ODBC driver that is being used is thread-safe, so it assumes
that all are not.
Because JavaSoft considers the JDBC-ODBC Bridge a testing and
development tool, it is unlikely that they will increase it
substantially, or make it part of the core Java API.
There are many middleware driver vendors who solve the problem of
connecting to ODBC data from Java applets over networks.
4.4 : How can I protect my database if someone can de-compile my Java
applet and steal my database information?
Java is notoriously easy to decompile. While any binary product can be
reverse-engineered, several Java de-compilers have appeared that
translate Java bytecode to source that is nearly identical to the
original.
Java obscufuators do not really help since connection information is
in all likelihood stored as a String, and therefore not obscured.
It is important to note that all database products face this threat.
Even native code applications which connect to database servers are
targets of simple reverse-engineering. Anyone can pull strings out of
any type of binary file with a hex editor or a disassembler. It might
even be easier to use a packet sniffer and listen for important host
and user connection information.
So, the short answer to this question is nothing.
The long answer is you, the programmer. You have several options to
make sure your database is secure in the case that your Java applet is
decompiled.
1. Your applet can use a userid on your database with very limited
permissions.
2. You can have the applet request the appropriate log-in information
from the user at run-time. You then are limiting your applet
users to those with database accounts, and are still the possible
target of a packet sniffer, but this may be acceptable in an
intranet.
3. You can remove JDBC from your applet and use some intermediary
server to send the data to your applet via some network protocol.
Many have used RMI or CORBA. Others have successfully used HTTP
and a CGI. My personal favorite is to use HTTP and Servlets (see
http://jserv.javasoft.com).
Exposing your database server to even limited access still opens you
up to a range of attacks, the easiest being denial-of-service attacks.
The last option is the safest. You can put your database server safely
behind a firewall.
Some middleware servers will let you combine several of these options.
They may map client user names and passwords to different usernames
and passwords used by the database server. This will prevent vital
account information from falling into untrusted hands. They may also
allow you to additionally limit database access rights, or provide
additional auditing and logging tools. Finally, a middleware server
can provide access to a database server that is safely behind a
firewall.
Your security choices depend entirely on how paranoid you want to be.
The rule of client-server security is that if you cannot control
security on the server, then you shouldn't provide access to untrusted
clients. The rule of Internet, is to assume the worst, so it
is probably best to err on the side of caution and put your database
safely out of harm's reach.
==========================================================================
5 : Programming JDBC
5.1 : How do I get a count of a ResultSet?
There is no JDBC method to count the number of results returned by a
ResultSet. In fact, JDBC and most database servers only know the count
of the records once they have stepped through them.
If you need to know the number of records in a ResultSet before you
step though it, probably the best way is to use a SELECT statement with
COUNT() before your SELECT statement which retrieves the data. Of
course there is no guarantee that the count will not change (unless
you lock the records).
5.2 : Why is there no method to step backwards in ResultSets? Why is
there a next() but no prev()?
The primary reason is because many databases do not support
bi-directional cursors. Many database servers only support stepping
through the result set in a single direction.
Of course, cursors this could be implemented at the driver level, and
in fact some JDBC driver vendors have indeed made their own additions
to the JDBC API that does precisely this.
Many have argued, though, that a well-written object oriented program
should not need to step backwards through a ResultSet, and that doing
so may be either inefficient or result in unreliable data results.
If you do need to step backwards and forwards through your ResultSet,
the best way is to make objects from each row and store them in a
Vector (or an array). This may take a lot of memory and computing
power to do, but it would take just as much (or almost as much) if
this functionality were built into the JDBC API or individual drivers.
If you plan on making changes to the values in the ResultSet, make
sure you lock the table you are working on if you are expecting
multi-user access.
==========================================================================
Glossary
JDBC
Java DataBase Connectivity. An API for database development in Java
developed by JavaSoft and Intersolv.
ODBC
Open Database Connectivity. An API for database development developed
by Microsoft for Microsoft Windows. It has since been ported to
Windows NT, Windows 95, Macintosh, and some UN*X systems.
SQL
Structured Query Language. A language used by database engines and
servers for data acquisition and definition.
==========================================================================
Resources
Books:
_Java Database Programming with JDBC_
Pratik Patel and Karl Moss (Coriolis, 1996)
info: http://www.coriolis.com/Site/MSIE/Books/Ind/jdpjdbc.htm
_DB Programming with JDBC and Java_
by George Reese (O'Reilly & Assoc, 1997)
info: http://www.ora.com/catalog/javadata
order: http://www.amazon.com/exec/obidos/ISBN=1565922700
On the 'Net:
The JavaSoft Web Site
http://splash.javasoft.com/jdbc/index.html
JDBC Mailing List
Send email to jdbc-r...@java.blackdown.org with the
word 'subscribe' in the subject line to join. It is archived at
http://www.blackdown.org/archive/jd...@java.blackdown.org/.
The com.lang.java.databases newsgroup
Java Programming FAQs
http://www.best.com/~pvdl
Michael Schuerig
Thornton Prime <th...@primenet.com> wrote:
> This FAQ (Frequently Asked Question list) has been compiled by me,
> Thornton Prime, to help answer some of the common questions regarding
> the use of JDBC.
Thanks!
Michael
--
Michael Schuerig When each word is read, would you know
mailto:uzs...@uni-bonn.de the difference if nothing was said?
http://www.uni-bonn.de/~uzs90z/ -Kansas, "Hopelessly Human"