The repro application (attached) contains code much like the following to make use of the CachedRowSetImpl

class:

  javax.sql.rowset.CachedRowSet rows = new com.sun.rowset.CachedRowSetImpl();

  rows.setCommand("SELECT * FROM CLOBTEST1");

  rows.execute(conn);

  rows.first();

  rows.setReadOnly(false);

                                  
  rows.updateString(1, "jon is awesome");

  rows.updateDouble(2, 3.14159);

  rows.updateInt(3, 69);

  rows.updateString(4, "jon is awesomer");

  rows.updateDate(5, new java.sql.Date(System.currentTimeMillis()));

  rows.updateRow();

  rows.acceptChanges();

 

In its implementation of the "acceptChanges" method, the CachedRowSetImpl class

submits a statement like the following to the JDBC driver:

  SELECT COL1, COL2, COL3, COL4, COL5, COL6

  FROM CLOBTEST1

  WHERE COL1 = ? AND COL2 = ? AND COL3 = ? AND COL4 = ? AND COL5 = ? AND COL6 = ?

 

The cause of the "ORA-00932: inconsistent datatypes: expected - got CLOB" error is
the presence of a CLOB column (COL6) in a WHERE clause comparision. Clob columns are
not searchable in Oracle. Therefore, it is illegal to include a condition check like
the following for a CLOB columns: "WHERE ClobCol = ?". But, this is exactly what
the CachedRowSetImpl is doing.

 
The same "ORA-00932: inconsistent datatypes: expected - got CLOB" error can be
produced by executing the following statement directly through JDBC (where COL6 is
a CLOB column):

  SELECT * FROM CLOBTEST1 WHERE COL6 = 'abc'

Below is the DDL required to run the reproducible and return the Oracle
error:

 CREATE TABLE CLOBTEST1
 (
 COL1 VARCHAR2(500 BYTE),
 COL2 NUMBER,
 COL3 INTEGER,
 COL4 NVARCHAR2(500),
 COL5 DATE,
 COL6 CLOB
 )

Once the above table is created, running the reproducible application
will reproduce the issue.

The problem has been reproduced using java versions 1.5.0_09, 1.5.0_11, 1.6.0_01 on Solaris 10 as well as Windows XP.