Because each database system is different, a unique driver must be written for each, since there is no universal driver that will translate between a JDBC application and any database system, unfortunately. Typically, the drivers are furnished by the vendor of the database. In our case, Cloudscape has written a driver for us to use.
If you needed to connect to another DBMS, you would have to locate a source for an appropriate driver. For example, if you wanted to use an Oracle DBMS, you would have to obtain an appropriate driver from Oracle.
The drivers are categorized by type, and each type is distinguished by:
- Driver components
- Language used to develop the components
- Locations where components reside
| Driver | Description |
|---|
| Type 1 | A JDBC driver that talks an ODBC driver. It provides a mechanism to use many of the existing Microsoft ODBC drivers. It requires that the ODBC driver be installed on the client machine.
It is supplied by Sun as part of the core JDBC software. It is also known as the JDBC-ODBCbridge. |
| Type 2 | A driver that requires some client-side binary code, but is partially comprised of Java code; JDBC calls are converted into the database vendor's protocol and mapped to the database-specific code of the target database,
usually in another language. |
| Type 3 | A driver written completely in Java. It is designed to use an indirect connection. It translates commands to a DBMS-independent format and passes them on to another process, usually a server of some sort.
That server re-translates those commands with a database-specific driver to a directly connected database. Responses are directed over the same, but reversed, route. |
| Type 4 | A driver also written in Java and for a specific DBMS. It is directly connected to a database and translates commands as required by that DBMS. It doesn't need client-side code to be invoked and loaded. |