The Structured Query Language (SQL) is a language for use with relational databases. One of the most used SQL statements is the SELECT statement: it is used to inspect a table of information. The statement:

SELECT last, first FROM ages WHERE age >= 21

would look at a table called ages and produce a new table containing the surnames and first names of the people having an age of at least 21 years.

Although SQL has been evolving since the early 1980's, it was in 1990 that the SQL Access Group defined the Call Level Interface (CLI) as a standard for accessing databases. To implement it, you need a driver that can translate a CLI call into the language used to access a particular database. Microsoft's Open Database Connectivity (ODBC), an API for Microsoft Windows that implements an extended version of the CLI, was first released in 1992. Most database vendors (including CA/Ingres, IBM, Informix, Oracle and Sybase as well as Microsoft) now support the ODBC API.

ODBC is an API written for the programming language C and although the Java Native Interface (JNI) allows a Java program to call a C function, there are many disadvantages with this approach:

• a Java program calling C code is one which is not so secure, robust and portable;
• calling C code is not usually possible from a Java applet because of security restrictions.

So, instead Java has its own API for submitting SQL statements to a database server: it is JDBC (sometimes called the Java DataBase Connectivity).

The JDBC API forms part of JDK 1.1.x: it is in the java.sql package. It was not part of JDK 1.0.2: however, if you have a JDK 1.0.2 program, a version of the JDBC API can be downloaded for use with JDK 1.0.2.

The JDBC API is implemented via a driver manager that can support multiple drivers connecting to different databases. A JDBC driver can either be written entirely in Java so that it can be downloaded as part of an applet or it can be implemented using native methods to bridge to existing database access libraries.

At the WWW page http://java.sun.com/products/jdbc/jdbc.drivers.html, Sun gives details of the drivers that are available from a number of vendors. On this page, they distinguish between four types of JDBC drivers:

1. ‘The JDBC-ODBC bridge provides JDBC access via most ODBC drivers. Note that some ODBC binary code and in many cases database client code must be loaded on each client machine that uses this driver, so this kind of driver is most appropriate on a corporate network, or for application server code written in Java in a 3-tier architecture.’
2. ‘A native-API partly-Java driver converts JDBC calls into calls on the client API for Oracle, Sybase, Informix, DB2, or other DBMS. Note that, like the bridge driver, this style of driver requires that some binary code be loaded on each client machine.’
3. ‘A net-protocol all-Java driver translates JDBC calls into a DBMS-independent net protocol which is then translated to a DBMS protocol by a server. This net server middleware is able to connect all its Java clients to many different databases. The specific protocol used depends on the vendor. In general, this is the most flexible JDBC alternative. ...’
4. ‘A native-protocol all-Java driver converts JDBC calls into the network protocol used by DBMSs directly. This allows a direct call from the client machine to the DBMS server and is a practical solution for Intranet access. Since many of these protocols are proprietary the database vendors themselves will be the primary source for this style of driver. Several database vendors have these in progress.’