| The API interface is made up of 4 main interfaces: |
| • java.sql DriverManager |
| • java. sql .Connection |
| • java. sql. Statement |
| • java.sql.Resultset |
| In addition to these, the following support interfaces are also available to the developer: |
| • java.sql.Callablestatement |
| • java. sql. DatabaseMetaData |
| • java.sql.Driver |
| • java. sql. PreparedStatement |
| • java. sql .ResultSetMetaData |
| • java. sql. DriverPropertymfo |
| • java.sql.Date |
| • java.sql.Time |
| • java. sql. Timestamp |
| • java.sql.Types |
| • java. sql. Numeric |
| DriverManager |
| This is a very important class. Its main purpose is to provide a means of managing the different types of JDBC database driver On running an application, it is the DriverManager’s responsibility to load all the drivers found in the system property j dbc . drivers. For example, this is where the driver for the Oracle database may be defined. This is not to say that a new driver cannot be explicitly stated in a program at runtime which is not included in jdbc.drivers. When opening a connection to a database it is the DriverManager’ s role to choose the most appropriate driver from the previously loaded drivers. |
| Connection |
| When a connection is opened, this represents a single instance of a particular database session. As long as the connection remains open, SQL queries may be executed and results obtained. More detail on SQL can be found in later chapters and examples found in Appendix A. This interface can be used to retneve information regarding the table descriptions, and any other information about the database to which you are connected. By using Connection a commit is automatic after the execution of a successful SQL statement, unless auto commit has been explicitly disabled. In this case a commit command must follow each SQL statement, or changes will not be saved. An unnatural disconnection from the database during an SQL statement will automatically result in the rollback of that query, and everything else back to the last successful commit. |
| Statement |
| The objective of the Statement interface is to pass to the database the SQL string for execution and to retrieve any results from the database in the form of a ResultSet. Only one ResultSet can be open per statement at any one time. For example, two ResultSets cannot be compared to each other if both ResultSets stemmed from the same SQL statement. If an SQL statement is re-issued for any reason, the old Resultset is automatically closed. |
| ResultSet |
| A ResultSet is the retrieved data from a currently executed SQL statement. The data from the query is delivered in the form of a table. The rows of the table are returned to the program in sequence. Within any one row, the multiple columns may be accessed in any order |
| A pointer known as a cursor holds the current retrieved record. When a ResUltSet is returned, the cursor is positioned before the first record and the next command (equivalent to the embedded SQL FETCH command) pulls back the first row. A ResultSet cannot go backwards. In order to re-read a previously retrieved row, the program must close the ResultSet and re-issue the SQL statement. Once the last row has been retrieved the statement is considered closed, and this causes the Resu1tSet to be automatically closed. |
| CallableStatement |
| This interface is used to execute previously stored SQL procedures in a way which allows standard statement issues over many relational DBMSs. Consider the SQL example: |
| SELECT cname FROM tnaine WHERE cname = var; |
| If this statement were to be stored, the program would need a way to pass the parameter var into the callable procedure. Parameters passed into the call are referred to sequentially, by number. When defining a variable type in JDBC the program must ensure that the type corresponds with the database field type for IN and OUT parameters. |
| DatabaseMetaData |
| This interface supplies information about the database as a whole. MetaData refers to information held about data. The information returned is in the form of ResultSet5. Normal ResultSet methods, as explained previously, may be used in this instance. If metadata is not available for the particular request then an SQLException will occur |
| Driver |
| For each database driver a class that implements the Driver interface must be provided. When such a class is loaded it should register itself with the DriverManager, which will then allow it to be accessed by a program. |
| PreparedStatement |
| A PreparedStatement object is an SQL statement which is pre-compiled and stored. This object can then be executed multiple times much more efficiently than preparing and issuing the same statement each time it is needed. When defining a variable type in JDBC, the program must ensure that the type corresponds with the database field type for IN and OUT parameters. |
| ResultSetMetaData |
| This interface allows a program to determine types and properties in any columns in a ResultSet. It may be used to find out a data type for a particular field before assigning its variable type. |
| DriverPropertyinfo |
| This class is only of interest to advanced programmers. Its purpose is to interact with a particular driver to determine any properties needed for connections. |
| Date |
| The purpose of the Date class is to supply a wrapper to the standard Java Date class which extends to allow JDBC to recognise an SQL DATE. |
| Time |
| The purpose of the Time class is to supply a wrapper to the standard Java Time class which extends to allow JDBC to recognise an SQL TIME. |
| Timestamp |
| The purpose of the Times tamp class is to supply a wrapper to the standard Java Date class which extends to allow JDBC to recognise an SQL TIMESTAMP |
| Types |
| The Types class determines any constants that are used to identify SQL types. |
| Numeric |
| The object of the Numeric class is to provide high precision in numeric computations that require fixed point resolution. Examples include monetary or encryption key applications. These equate to database SQL NUMERIC or DECIMAL types. |
| Driver Interface |
| The driver side of the JDBC layer is the part that interfaces to the actual database, and therefore is generally written by database vendors. Most developers only need to know how to install and use drivers. The JDBC Driver API defines a set of interfaces which have to be implemented by a vendor |
| JDBC is based on Microsoft’s Open Database Connectivity (ODBC) interface which many of the mainstream databases have adopted. Therefore, a JDBCODBC bridge is supplied as part of JDBC, which allows most databases to be accessed before the Java driver is released. Although efficient and fast, it is recommended that the actual database JDBC driver is used rather than going through another level of abstraction with ODBC. |
| Developers have the power to develop and test applications that use the JDBC-ODBC bridge. If and when a proper driver becomes available they will be able to slot in the new driver and have the applications utilise it instantly, without the need for rewriting. However, do not assume the JDBC-ODBC bridge is a bad alternative. It is a small and very efficient way of accessing databases. |
| Application Areas |
| JDBC has been designed and implemented for use in connecting to databases. Fortunately, JDBC has made no restrictions, over and above the standard Java security mechanisms, for complete systems. To this end, a number of overall system configurations are feasible for accessing databases. |
| 1. Java application which accesses local database |
| 2. Java applet accesses server-based database |
| 3. Database access from an applet via a stepping stone |