Corporate Info  |  News  |  Solutions  |  Products  |  Partners  |  Services  |  Events  |  Download  |  How To Buy
	e-docs   |   Site Map   |   Search   |   Contact   |   Glossary   |   WebLogic Server Documentation

Using WebLogic jDriver for Informix

Introduction

What's in this document

Mapping of types from Informix to WebLogic jDriver for Informix to Java

Implementing with WebLogic jDriver for Informix

Connecting to an Informix DBMS

Connection example

Other properties you can set for WebLogic jDriver for Informix

Overview of data manipulation

Making a simple SQL query

Inserting, updating, and deleting records

Creating and using stored procedures and functions

Disconnecting and closing objects

Retrieving the SERIAL column after an insert

Support for the Informix INTERVAL data type

Using ResultSetMetaData methods

Using autocommit mode

Support for Informix-specific features

Retrieving VARCHAR/CHAR data as bytes

Codeset support

Using Unicode streams in a prepared statement

What is currently supported in WebLogic jDriver for Informix

More Resources

Code examples

WebLogic jDriver for Informix is a new name for the product previously called jdbcKona/Informix4.

This document includes documentation on how to set up and use WebLogic jDriver for Informix (formerly known as FastForward from Connect Software, acquired in April 1998). This database driver is a Type 4, pure-Java, two-tier driver. It requires no client-side libraries since it connects to the database via the proprietary vendor protocol at the wire-format level. Consequently, unlike Type 2, two-tier drivers, it makes no "native" calls; it is written exclusively in Java.

A Type 4 driver is similar to a Type 2 driver in other ways, however. Both Type 2 and Type 4 drivers are two-tier drivers; that means that each client requires an in-memory copy of the driver to support its connection to the database.

WebLogic jDriver for Informix supports concurrent ResultSet execution; that is, you don't have to finish with and close one ResultSet on a Connection before you can open and work with another. However, the driver cannot support both concurrent ResultSet execution and client-side caching.

WebLogic jDriver for Informix supports Informix OnLine versions 7.x and 9.x, with 7.x data types plus the 9.x INT8 and SERIAL8 data types.

Before you begin working with WebLogic jDriver for Informix, make sure you have installed the driver according to the installation instructions and, in particular, that you know the port on which the database is listening for connection requests.

The following steps tell you how to set up your application to connect to Informix using WebLogic jDriver for Informix. In general, connecting happens in three steps:

1. Load the JDBC driver by calling Class.forName().newInstance() with the full class name of the WebLogic jDriver for Informix JDBC driver class, and casting it to a java.sql.Driver object. This procedure properly loads and registers the JDBC driver. For example:

   Driver myDriver = (Driver)
    Class.forName("weblogic.jdbc.informix4.Driver").newInstance();

2. Create a java.util.Properties object describing the connection. This object contains name-value pairs containing information such as user name, password, database name, server name, and port number. For example:

   Properties props = new Properties();
   props.put("user",         "scott");
   props.put("password",     "secret");
   props.put("db",           "myDB");
   props.put("server",       "myHost");
   props.put("port",         "8659");

3. Create a JDBC Connection object, which becomes an integral piece in your JDBC operations, by calling the Driver.connect() method, which takes as its parameters the URL of the driver and the java.util.Properties object you created in step 2. For example:

   Connection conn =  
     myDriver.connect("jdbc:weblogic:informix4", props);

In steps 1 and 3, you are describing the JDBC driver: in the first step, you use the full package name of the driver. Note that it is dot-delimited. In the third step, you identify the driver with its URL, which is colon-delimited. The URL must include at least weblogic:jdbc:informix4, and may include other information, including the server host name and the database name.

This example shows how to use a Properties object to connect to a database named "myDB" on a server named "myHost":

Properties props = new Properties();
props.put("user",         "scott");
props.put("password",     "secret");
props.put("db",           "myDB");
props.put("server",       "myHost");
props.put("port",         "8659");

Driver myDriver = (Driver)
  Class.forName("weblogic.jdbc.informix4.Driver").newInstance();
Connection conn =  
  myDriver.connect("jdbc:weblogic:informix4", props);

You can combine the "db", "server", and "port" properties into one "server" property, as in this example:

Properties props = new Properties();
props.put("user",         "scott");
props.put("password",     "secret");
props.put("server",       "myDB@myHost:8659");

Driver myDriver = (Driver)
  Class.forName("weblogic.jdbc.informix4.Driver").newInstance();
Connection conn  =  
  myDriver.connect("jdbc:weblogic:informix4", props);

There are any number of variations on supplying information in the URL or in the Properties object. Whatever information you pass in the URL of the driver, you don't need to include in the Properties object. For more information, see Using URLs to set properties for a JDBC connection.

There are other Informix-specific properties that you can set in the connection URL or Properties object. These properties give you more control over an Informix-specific environment. For more information on these variables, please refer to your Informix documentation.

weblogic.informix4.login_timeout_secs=seconds_to_wait

When an attempt to log into an Informix server times out, WebLogic jDriver for Informix returns an SQLException. By default, the driver waits 90 seconds before it times out. You can modify the timeout period by setting this property to the number of seconds you want to wait before returning an SQLException.

weblogic.informix4.delimited_identifiers=y

The Informix environment variable DELIMIDENT is used to enable and disable ANSI SQL Delimited Identifiers. In older versions before the WebLogic acquisition, this feature was permanently set on ("y"). The default is now off ("n").

weblogic.informix4.db_money=currency

The Informix environment variable DBMONEY is used to set the display of the currency symbol. In older versions before the WebLogic acquisition, "$." was hard-coded as the value for this variable. The default value is now "$." which can be overridden with this property.

weblogic.informix4.db_date=dateformat

The Informix environment variable DBDATE allows a user to specify the input format of dates. It sets the Informix DBDATE environment variable at login. The default value is "Y4MD". Two-digit years (formats containing Y2) are not supported by the driver. Note that this variable cannot be used to correctly format a date obtained from a ResultSet.getString() statement. Instead, use ResultSet.getDate() to obtain a java.util.Date object and then format the date in your code.

Here is an example of these properties used in a URL. Note that the URL is always used as a single line but has been broken here for simplicity.

  jdbc:weblogic:informix4:mydb@host:1493
  ?weblogic.informix4.delimited_identifiers=y
  &weblogic.informix4.db_money=DM
  &weblogic.informix4.db_date=Y4MD

Note the use of "?" and "&", which are special characters for URLs. For more on using URLs with WebLogic, read the Developers Guide, Using URLs to set properties for a JDBC Connection.

Here's how these properties might be used with a Properties object:

Properties props = new Properties();
props.put("user",                                     "scott");
props.put("password",                                 "tiger");
props.put("weblogic.informix4.delimited_identifiers", "y");
props.put("weblogic.informix4.db_money",              "DM");

Connection conn = myDriver.connect
   (jdbc:weblogic:informix4:myDB@myHost:8659",props);

This section provides an overview of the basic steps for executing SQL data queries, making inserts and updates, using stored procedures, and using callable statements. These steps follow basic JDBC methodology and are intended as a brief introduction to data manipulation with JDBC. For additional information, you should consult your Informix documentation as well as Java-oriented texts discussing JDBC. You may also wish to consult JavaSoft's JDBC tutorial.

The most fundamental task in database access is to retrieve data. With jdbcKona, this is a three-step process:

1. Create a Statement to send a SQL query to the DBMS

2. Execute the Statement

3. Retrieve the results into a ResultSet. In this example, we execute a simple query on the Employee table (alias "emp") and display data from three of the columns. We also access and display metadata about the table from which the data was retrieved. Note that we close the Statement at the end.

   Statement stmt = conn.createStatement();
   stmt.execute("select * from emp");
   ResultSet rs = stmt.getResultSet();
   
   while (rs.next()) {
     System.out.println(rs.getString("empid") + " - " +
                        rs.getString("name")  + " - " +
                        rs.getString("dept"));
     }
   
   ResultSetMetaData md = rs.getMetaData();
   
   System.out.println("Number of columns: " + 
         md.getColumnCount());
   for (int i = 1; i 

We illustrate three common database tasks in this step: inserting, updating, and deleting records from a database table. We use a JDBC PreparedStatement for these operations; we create the PreparedStatement, then execute it and close it.

A PreparedStatement (subclassed from JDBC Statement) allows you to execute the same SQL over and over again with different values. PreparedStatements use the JDBC "?" syntax.

  String inssql = 
     "insert into emp(empid, name, dept) values (?, ?, ?)";
  PreparedStatement pstmt = conn.prepareStatement(inssql);

  for (int i = 0; i 

We also use a PreparedStatement to update records. In this example, we add the value of the counter "i" to the current value of the "dept" field.

  String updsql = 
     "update emp set dept = dept + ? where empid = ?";
  PreparedStatement pstmt2 = conn.prepareStatement(updsql);

  for (int i = 0; i 

Finally, we use a PreparedStatement to delete the records that we added and then updated.

  String delsql = "delete from emp where empid = ?";
  PreparedStatement pstmt3 = conn.prepareStatement(delsql);

  for (int i = 0; i 

You can use WebLogic jDriver for Informix to create, use, and drop stored procedures and functions. First, we execute a series of Statements to drop a set of stored procedures and functions from the database.

  Statement stmt = conn.createStatement();
  try {stmt.execute("drop procedure proc_squareInt");}
  catch (SQLException e) {;}
  try {stmt.execute("drop procedure func_squareInt");}
  catch (SQLException e) {;}
  try {stmt.execute("drop procedure proc_getresults");}
  catch (SQLException e) {;}
  stmt.close();

We use a JDBC Statement to create a stored procedure or function, and then we use a JDBC CallableStatement (subclassed from Statement) with the JDBC "?" syntax to set IN and OUT parameters.

Stored procedure input parameters are mapped to JDBC IN parameters, using the CallableStatement.setXXX() methods, like setInt(), and the JDBC PreparedStatement "?" syntax. Stored procedure output parameters are mapped to JDBC OUT parameters, using the CallableStatement.registerOutParameter() methods and JDBC PreparedStatement "?" syntax. A parameter may be both IN and OUT, which requires both a setXXX() and a registerOutParameter() call to be done on the same parameter number.

In this example, we use a JDBC Statement to create a stored procedure, then we execute the stored procedure with a CallableStatement. We use the registerOutParameter() method to set an output parameter for the squared value.

  Statement stmt1 = conn.createStatement();
  stmt1.execute
    ("CREATE OR REPLACE PROCEDURE proc_squareInt " +
    "(field1 IN OUT INTEGER, field2 OUT INTEGER) IS " + 
    "BEGIN field2 := field1 * field1; field1 := " +
    "field1 * field1; END proc_squareInt;");
  stmt1.close();


  String sql = "{call proc_squareInt(?, ?)}";
  CallableStatement cstmt1 = conn.prepareCall(sql);

  // Register out parameters
  cstmt1.registerOutParameter(2, java.sql.Types.INTEGER);
  for (int i = 0; i 

In the next example, we use similar code to create and execute a stored function that squares an integer.

  Statement stmt2 = conn.createStatement();
  stmt2.execute("CREATE OR REPLACE FUNCTION func_squareInt " +
                "(field1 IN INTEGER) RETURN INTEGER IS " +
                "BEGIN return field1 * field1; " +
"END func_squareInt;");
  stmt2.close();


  sql = "{ ? = call func_squareInt(?)}";
  CallableStatement cstmt2 = conn.prepareCall(sql);

  cstmt2.registerOutParameter(1, Types.INTEGER);
  for (int i = 0; i 

This next example uses a stored procedure named sp_getmessages (the code for this stored procedure is not included with this example) named sp_getmessages, which takes a message number as an input parameter and returns the message text in a ResultSet as an output parameter. Note that you must process all ResultSets returned by a stored procedure using the Statement.execute() and Statement.getResult() methods before OUT parameters and return status are available.

First, we set up the three parameters to the CallableStatement:

1. Parameter 1 (output only) is the stored procedure return value

2. Parameter 2 (input only) is the msgno argument to sp_getmessage

3. Parameter 3 (output only) is the message text return for the message number

      String sql = "{ ? = call sp_getmessage(?, ?)}";
       CallableStatement stmt = conn.prepareCall(sql);
   
       stmt.registerOutParameter(1, java.sql.Types.INTEGER);
       stmt.setInt(2, 18000);           // msgno 18000
       stmt.registerOutParameter(3, java.sql.Types.VARCHAR);

We execute the stored procedure and check the return value to see if the ResultSet is empty. If it is not, we use a loop to retrieve and display its contents.

  boolean hasResultSet = stmt.execute();
  while (true)
  {
    ResultSet rs = stmt.getResultSet();
    int updateCount = stmt.getUpdateCount();
    if (rs == null && updateCount == -1) // no more results
      break;
    if (rs != null) {
      // Process the ResultSet until it is empty
      while (rs.next()) {
        System.out.println
        ("Get first col by id:" + rs.getString(1));
      }
    } else {
      // we have an update count
      System.out.println("Update count = " + 
       stmt.getUpdateCount());
    }
    stmt.getMoreResults();
  }

Once we have finished processing the ResultSet, the OUT parameters and return status are available.

  int retstat = stmt.getInt(1);
  String msg = stmt.getString(3);

  System.out.println("sp_getmessage: status = " +
                     retstat + " msg = " + msg);
  stmt.close();

There are occasions on which you will want to call the commit() method to commit changes you have made to the database before you close the connection.

When autocommit is set to true (the default JDBC transaction mode) each SQL statement is its own transaction. After we created the Connection for these examples, however, we set autocommit to false; in this mode, the Connection always has an implicit transaction associated with it, and any call to the rollback() or commit() methods will end the current transaction and start a new one. Calling commit() before close() ensures that all of the transactions are completed before closing the Connection.

Just as you close Statements, PreparedStatements, and CallableStatements when you have finished working with them, you should always call the close() method on the connection as final cleanup in your application, in a try {} block, and you should catch exceptions and deal with them appropriately. The final two lines of this example include a call to commit and then a call to close the connection.

  conn.commit();
  conn.close();

weblogic.jdbc.informix4.Statement

You can obtain serial values after an insert by using the Statement.getSerialNumber() method, a WebLogic extension to JDBC in WebLogic jDriver for Informix. This allows you to track the index order of rows as you add them to the table. Note that you must create the table with a SERIAL column.

To use this extension, you'll need to explicitly cast your Statement object to weblogic.jdbc.informix4.Statement.

Here's a simple code example that illustrates how to use the getSerialNumber() method.

  weblogic.jdbc.informix4.Statement stmt =
    (weblogic.jdbc.informix4.Statement)conn.createStatement();
  String sql = "CREATE TABLE test ( s SERIAL, count INT )";
  stmt.executeUpdate(sql);

  for (int i = 100; i 

To use the Informix INTERVAL data type, import weblogic.jdbc.common.InformixInterval and cast your objects to weblogic.jdbc.common.InformixInterval.

Use a literal string in the Informix INTERVAL format to enter an INTERVAL value in a SQL statement. Use preparedStatement.setString() to set an INTERVAL value parameter in a prepared statement. For retrieving INTERVAL data from an Informix server, WebLogic jDriver for Informix supports three standard API methods on a ResultSet:

• ResultSet.getString() returns a String representation of the interval in the standard Informix format. Returns null if the interval is null.

• ResultSet.getBytes() returns the actual bytes the server returns to represent the interval.

• ResultSet.getObject() returns an object of type weblogic.jdbc.common.InformixInterval. Returns null if the interval is null.

The InformixInterval interface provides the following public methods:

String getString() throws SQLException

Identical to ResultSet.getString()

int getYear() throws SQLException

Returns the signed year of the INTERVAL, zero if YEAR is not defined

int getMonth() throws SQLException

Returns the signed year of the interval, zero if MONTH is not defined

int getDay() throws SQLException

Returns the signed day of the interval, zero if DAY is not defined

int getHour() throws SQLException

Returns the signed hour of the interval, zero if HOUR is not defined

int getMinute() throws SQLException

Returns the signed minute of the interval, zero if MINUTE is not defined

int getSecond() throws SQLException

Returns the signed second of the interval, zero if SECOND is not defined

int getFraction() throws SQLException

Returns the actual value of the FRACTION times 10**5

The metadata the Informix server returns with query results is available via ResultSetMetaData methods. However, the Informix server does not return information for the following:

Unlike other database system attributes, the autocommit mode of an Informix database cannot be set dynamically. It is defined when the database is created. You cannot change it with a call to the Connection.setAutoCommit method. Only non-ANSI, non-logged databases support changing autocommit.

The JDBC spec says that the autocommit mode should be true by default, but it is not possible to do this with Informix. All that you can do is determine what the autocommit mode is. To change the autocommit state, you must rebuild your database (for more information, see the information on "CREATE DATABASE" in the Informix docs).

This affects how transactions and locking work. A JDBC program could behave very differently depending on how the Informix database is created.

Before you depend on autocommit, you should know the setting of autocommit for the database you'll be using. You can check its state with the Connection.getAutoCommit() method, which returns true if autocommit is enabled. For Informix, this method returns false by default for ANSI databases; it may return true or false, depending on how the database was created, for a non-ANSI database.

Here is what is supported in WebLogic jDriver for Informix when you call the Connection.setAutoCommit() method:

• For ANSI databases, only autocommit=false is supported.

• For non-ANSI databases, autocommit can be set to either true or false.

• For non-ANSI databases without logging, only autocommit=true is supported.

Your program must then operate in accordance with the state of your Informix database.

If you are using a non-ANSI database and you set autocommit to false, all transactional SQL must be carried out using the Connection.commit() or Connection.rollback() methods. You should never execute the explicit transaction controls BEGIN WORK, COMMIT WORK, or ROLLBACK WORK calls on a Statement, since WebLogic jDriver for Informix uses transaction commands internally to simulate an autocommit=false status. You should always control a transaction using commit() and rollback() methods in the Connection class.

For non-ANSI databases without logging, autocommit=false cannot be supported, since transactions are not supported. Consequently, only autocommit=true is supported for use with such databases.

WebLogic jDriver for Informix includes support for other Informix-specific features that may not be part of the JDBC specification, but that add power when writing a client application for an Informix database.

WebLogic jDriver for Informix provides an extension to JDBC for Informix that allows users to retrieve VARCHAR and CHAR columns using the ResultSet.getBytes(String columnName) and ResultSet.getBytes(int columnIndex) methods. Although this is outside the scope of the JDBC specification, this was implemented in response to customer requests. No cast of the ResultSet is required to take advantage of this feature.

As a Java application, WebLogic jDriver for Informix handles character strings as Unicode strings. To exchange character strings with a database that may operate with a different codeset, you must set the weblogic.codeset connection property to the proper JDK codeset. If there is no direct mapping between the codeset of your database and the character sets provided with the JDK, you can set the weblogic.codeset connection property to the most appropriate Java character set. You can find the List of supported encodings at the JavaSoft website.

For example, to use the cp932 codeset, create a Properties object and set the weblogic.codeset property before calling Driver.connect(), as in this example:

java.util.Properties props = new java.util.Properties();
props.put("weblogic.codeset", "cp932");
props.put("user", "scott");
props.put("password", "tiger");

String connectUrl = "jdbc:weblogic:informix4:myDB@myHost:1493";

Driver myDriver = (Driver)
  Class.forName("weblogic.jdbc.informix4.Driver").newInstance();
  Connection conn = 
     myDriver.connect(connectUrl, props);

weblogic.jdbcbase.informix4.UnicodeInputStream()

If you are using the PreparedStatement.setUnicodeStream method, you can either create your own InputStream object, or you can create a weblogic.jdbc.informix4.UnicodeInputStream object, using a String value in the constructor. Here's an example that shows how to input a Unicode stream into an Informix TEXT column, (using the connectUrl and props objects created above):

Driver myDriver = (Driver)
  Class.forName("weblogic.jdbc.informix4.Driver").newInstance();
  Connection c = 
     myDriver.connect(connectUrl, props);

  PreparedStatement ps = 
    c.prepareStatement("insert into dbTEST values (99,?)"); 
        
  String s = new String("\u93e1\u68b0\u897f");
  weblogic.jdbcbase.informix4.UnicodeInputStream uis =
    new weblogic.jdbcbase.informix4.UnicodeInputStream(s);

  try {
    ps.setUnicodeStream(1,uis,uis.available());
  } 
  catch (java.io.IOException ioe) {
    System.out.println("--  IO Exception in setUnicodeStream");
  }
  ps.executeUpdate();

To retrieve data from a UnicodeInputStream you can use java.io.InputStream. For example,

  InputStream uisout = rs.getUnicodeStream(2);
  int i=0;
  while (true) {
  try {
    i = uisout.read();    // read 1 byte at a time from UnicodeStream
  } 
  catch (IOException e) {
    System.out.println("-- IOException reading UnicodeStream");
  }

For more information, check the full example included in the distribution, in the examples/jdbc/informix4 directory.

WebLogic jDriver for Informix is a complete and compliant implementation of the JDBC specification, except for those features described in JDBC that are either unsupported or unavailable in Informix. Since there is often confusion about the implementation the DatabaseMetaData interface, we list all of its methods here. Most are supported; some are planned for a future release, and some (because of Informix limitations or implementations) will not be supported for this JDBC driver.

The following DatabaseMetaData methods are supported:

allProceduresAreCallable()

allTablesAreSelectable()

dataDefinitionCausesTransactionCommit()

dataDefinitionIgnoredInTransactions()

doesMaxRowSizeIncludeBlobs()

getCatalogSeparator()

getCatalogTerm()

getColumns()

getDatabaseProductName()

getDatabaseProductVersion()

getDefaultTransactionIsolation()

getDriverMajorVersion()

getDriverMinorVersion()

getDriverName()

getDriverVersion()

getExportedKeys()

getExtraNameCharacters()

getIdentifierQuoteString()

getImportedKeys()

getMaxBinaryLiteralLength()

getMaxCatalogNameLength()

getMaxCharLiteralLength()

getMaxColumnNameLength()

getMaxColumnsInGroupBy()

getMaxColumnsInIndex()

getMaxColumnsInOrderBy()

getMaxColumnsInSelect()

getMaxColumnsInTable()

getMaxConnections()

getMaxCursorNameLength()

getMaxIndexLength()

getMaxProcedureNameLength()

getMaxRowSize()

getMaxSchemaNameLength()

getMaxStatementLength()

getMaxStatements()

getMaxTableNameLength()

getMaxTablesInSelect()

getMaxUserNameLength()

getNumericFunctions()

getPrimaryKeys()

getProcedures()

getProcedureTerm()

getSchemas()

getSchemaTerm()

getSearchStringEscape()

getSQLKeywords()

getStringFunctions()

getSystemFunctions()

getTables()

getTableTypes()

getTimeDateFunctions()

getTypeInfo()

getURL()

getUserName()

isCatalogAtStart()

isReadOnly()

nullPlusNonNullIsNull()

nullsAreSortedAtEnd()

nullsAreSortedAtStart()

nullsAreSortedHigh()

nullsAreSortedLow()

storesLowerCaseIdentifiers()

storesLowerCaseQuotedIdentifiers()

storesMixedCaseIdentifiers()

storesMixedCaseQuotedIdentifiers()

storesUpperCaseIdentifiers()

storesUpperCaseQuotedIdentifiers()

supportsAlterTableWithAddColumn()

supportsAlterTableWithDropColumn()

supportsANSI92EntryLevelSQL()

supportsANSI92FullSQL()

supportsANSI92IntermediateSQL()

supportsCatalogsInDataManipulation()

supportsCatalogsInIndexDefinitions()

supportsCatalogsInPrivilegeDefinitions()

supportsCatalogsInProcedureCalls()

supportsCatalogsInTableDefinitions()

supportsColumnAliasing()

supportsConvert()

supportsCoreSQLGrammar()

supportsCorrelatedSubqueries()

supportsDataDefinitionAndDataManipulationTransactions()

supportsDataManipulationTransactionsOnly()

supportsDifferentTableCorrelationNames()

supportsExpressionsInOrderBy()

supportsExtendedSQLGrammar()

supportsFullOuterJoins()

supportsGroupBy()

supportsGroupByBeyondSelect()

supportsGroupByUnrelated()

supportsIntegrityEnhancementFacility()

supportsLikeEscapeClause()

supportsLimitedOuterJoins()

supportsMinimumSQLGrammar()

supportsMixedCaseIdentifiers()

supportsMixedCaseQuotedIdentifiers()

supportsMultipleResultSets()

supportsMultipleTransactions()

supportsNonNullableColumns()

supportsOpenCursorsAcrossCommit()

supportsOpenCursorsAcrossRollback()

supportsOpenStatementsAcrossCommit()

supportsOpenStatementsAcrossRollback()

supportsOrderByUnrelated()

supportsOuterJoins()

supportsPositionedDelete()

supportsPositionedUpdate()

supportsSchemasInDataManipulation()

supportsSchemasInIndexDefinitions()

supportsSchemasInPrivilegeDefinitions()

supportsSchemasInProcedureCalls()

supportsSchemasInTableDefinitions()

supportsSelectForUpdate()

supportsStoredProcedures()

supportsSubqueriesInComparisons()

supportsSubqueriesInExists()

supportsSubqueriesInIns()

supportsSubqueriesInQuantifieds()

supportsTableCorrelationNames()

supportsTransactionIsolationLevel()

supportsTransactions()

supportsUnion()

supportsUnionAll()

usesLocalFilePerTable()

usesLocalFiles()

Support for the following methods is implemented and under testing:

getBestRowIdentifier()

getColumnPrivileges()

getTablePrivileges()

Support for the following methods is planned:

getIndexInfo()

supportsConvert()

These methods will not be supported:

getCatalogs()

getCrossReference()

getProcedureColumns()

getVersionColumns()

• WebLogic JDBC Options

  Contains information on other WebLogic JDBC drivers, additional documentation, support resources, and more.

• Using connection pools with server-side Java (in Using WebLogic HTTP Servlets)

• Creating and using connection pools

• JavaSoft's JDBC tutorial
  

Code examples

We also ship a number of code examples in the distribution that will help you get started. Code examples are located in the weblogic/informix4/examples/ directory in the distribution.