Technical data

16 Managing JDBC Connectivity
16-34 Administration Guide
statement such as select * from emp and then drop and recreate the emp table, the
next time you run the cached statement, the statement will fail because the exact
emp
table that existed when the statement was prepared, no longer exists.
Likewise, prepared statements are bound to the data type for each column in a table in
the database at the time the prepared statement is cached. If you add, delete, or
rearrange columns in a table, prepared statements stored in the cache are likely to fail
when run again.
Using setNull In a Prepared Statement
When using the WebLogic jDriver for Oracle to connect to the database, if you cache
a prepared statement that uses a
setNull bind variable, you must set the variable to
the proper data type. If you use a generic data type, as in the following example, the
statement will fail when it runs with a value other than null.
java.sql.Types.Long sal=null
.
.
.
if (sal == null)
setNull(2,int)//This is incorrect
else
setLong(2,sal)
Instead, use the following:
if (sal == null)
setNull(2,long)//This is correct
else
setLong(2,sal)
This issue occurs consistently when using the WebLogic jDriver for Oracle. It may
occur when using other JDBC drivers.
Prepared Statements in the Cache May Reserve Database Cursors
When WebLogic Server caches a prepared statement, the prepared statement may open
a cursor in the database. If you cache too many statements, you may exceed the limit
of open cursors for a connection. To avoid exceeding the limit of open cursors for a
connection, you can change the limit in your database management system or you can
reduce the prepared statement cache size for the connection pool.