This chapter explains the JDBC components that enable JDBC connectivity to Ingres data sources. It provides a description of each component, a list of supported API features, driver and server configuration information, and guidelines for implementing Java applications in the Ingres environment.
|
|
|
Ingres JDBC consists of the following components:
|
|
|
The Ingres JDBC Driver is a pure Java implementation of the JDBC 3.0 API released with the Sun Java 2 SDK, version 5.0. The driver supports application, applet, and servlet access to Ingres data sources through the DAS.
Note: The JDBC driver provided in the Ingres 2.6 release continues to be supported in this current release. For migration instructions related to the JDBC driver, see the Migration Guide.
The Ingres JDBC Driver supports the following JDBC 3.0 features:
The Ingres JDBC Driver is delivered as a single Java archive file, named iijdbc.jar, located in the library directory (lib) of the Ingres instance. Depending on the Java environment used, access to the driver requires adding the Java archive to the CLASSPATH environment setting or as a resource in the appropriate utility. For browser/applet access, the Java archive must be copied to the Web Server directories.
|
|
|
The JDBC information utility, JdbcInfo, loads the Ingres JDBC driver and displays its internal release information. The class files for the JdbcInfo utility are located in the library directory (lib) of the Ingres instance.
You can invoke the JdbcInfo utility from the command line with the following parameters:
Displays the internal driver release of the Ingres JDBC Driver.
Attempts to establish a JDBC connection to the target database using the specified URL. If successful, it displays the Ingres JDBC Driver name and release that serviced the URL connection.
Attempts to establish a low-level connection to the DAS associated with host port. If successful, it displays the internal driver release of the Ingres JDBC Driver.
|
|
|
The Ingres JDBC Driver is compliant with the JDBC 3.0 API specification. JDBC 3.0 API interfaces are fully supported with the following exceptions:
Ingres and Open SQL do not support the description of dynamic parameters. The method 'getParameterMetaData()' throws an exception when called.
The Ingres DBMS returns only a single table key or a single object key per insert statement. Ingres does not return table and object keys for INSERT AS SELECT statements. Depending on the keys that are produced by the statement executed, auto-generated key parameters in execute(), executeUpdate(), and prepareStatement() methods are ignored and getGeneratedKeys() returns a result-set containing no rows, a single row with one column, or a single row with two columns. The Ingres JDBC Driver returns table and object keys as BINARY values.
Result sets generated by executeQuery() requests are always TYPE_FORWARD_ONLY (non-scrollable) and CLOSE_CURSORS_AT_COMMIT (non-holdable). Methods associated with scrolling throw SQLExceptions. The isLast() method cannot always detect when the ResultSet is positioned on the last row and may return false instead of returning true.
The JDBC data types DATALINK, BLOB, CLOB, ARRAY, REF, DISTINCT, STRUCT, and JAVA_OBJECT are not supported. The storage or mapping, of Java objects (SQLInput, SQLOutput, and SQLData) is also not supported. Methods associated with these data types throw exceptions when called.
Ingres stores date/time values in GMT (same as Java). With an Ingres DBMS, the Ingres JDBC Driver handles all date/time values in GMT and calendars provided in setXXX() and getXXX() methods are ignored. EDBC servers and Enterprise Access gateways do not reference date/time values to a particular time zone. The Ingres JDBC Driver uses the local time zone when accessing a non-Ingres DBMS Server, and utilizes calendars if provided. Calendars are also used for TIME WITHOUT TIME ZONE and TIMESTAMP WITHOUT TIME ZONE values.
Batched execution for Statements, PreparedStatements, and CallableStatements is supported by individual execution of each batched request. The driver implementation for batch updates is only as efficient as an application making individual update requests.