ORA-00932: inconsistent datatypes: expected - got CLOB

JDEList,

I am getting an error in our DV environment for the web only and not on the fat client for a custom application that updates a custom table. The error is as follows:

ORA-00932: inconsistent datatypes: expected - got CLOB

I have attached the jasdebug log extract for the error.

Can anyone explain why this error is occuring and/or how to fix it.

System Config:
Oracle JD Edwards EnterpriseOne,
E8.11sp1 8.96C1, ES Sun, Oracle DB 9207, Websphere 6 Win2K3.
Forms: Create!form Server 3/Server 6

Peter,

1. Are the Oracle Client versions on the web server and the fat client identical?

2. Do you have a CLOB in the table? If yes - what Data Dictionary alias did you map it to?

Did the keys change? This is cached on the web server.

Larry, Darren,

Thanks for your replies.

From Larry:
[ QUOTE ]
1. Are the Oracle Client versions on the web server and the fat client identical?


[/ QUOTE ]

From Darren:
[ QUOTE ]
Did the keys change? This is cached on the web server.

[/ QUOTE ]

I did not make this clear on my original post, but this all take place on the one development machine - there is no separate web server involved. I run the custom application from within OMW (fat development client), by clicking the run html button. This starts an IE browser window, logs on(?) and opens the application. There is no difference if I then close the application and run it again (in IE) fron the fast path box.

From Larry:
[ QUOTE ]
2. Do you have a CLOB in the table? If yes - what Data Dictionary alias did you map it to?

[/ QUOTE ]

The table does not have any CLOB type columns, they are all NVARCHAR2 of lengths 4 (1 column), 2 (1 column), 10 (1 column) and 255 (79 columns). I have attached the SQL statement to create the table - though it was generated from JDE. All columns are based on custom data dictionary items.

Previously, I have successfully added rows to the table using this custom application. It is only the update that is causing problems.

JDEList,

This an update.

I submitted a case to Oracle. They replied with SAR 8448328, to which my problem may be related, which is apparently fixed in Tools Release 8.96.1.4 and 8.98 but not in 8.97 (as yet?). This is a problem for us as we are in the middle of planning for an upgrade to 8.97. Therefore I will have to request a POC (an untested quick fix).

Additionally, solution id 200801000 was mentioned, which refers to variable length strings (data type 20 for the data item asociated with the tabel column) saying "The runtime engine does not support the use of this type of field within an application".

The work around is to change the data dictionary data items from data type 20 to data type 2 and regenerate the table.

At the moment I am playing around with changing the data type in our development/test system (separate to our production system). The problem is that the custom table is in production, and I am working on a maintenance application for it. Which may mean that I will have to change the data dictionary in production - something that I always try to avoid, even with custom data items.

That's the state of play at the moment.

Ouch Peter!

bad news - particularly since I've used some variable length strings in 1 custom app - could mean trouble when we upgrade

Thx for the update!

Peter,

I had noticed the error (and some other similar JAS_MSG type errors) that occur more-frequently from the local http client (developer client) that do not occur on the full web client.

For example - the JAS_MSG I was getting with table triggers does not occur on the server (web'd) - but will trip every developer client when we tested on local web (works great on local FAT).

Your example, though similar to mine - has added some insight to the issue - thank you for providing bOrgacle's feedback to the issue

(db)

------------------
Current: 8.12|8.97.xx|iSeries

Update:

I changed one of the custom data items (on which a table column was based) from data type 20 to date type 2 and regenerated the table. The format of the column changed from NVARCHAR2 to NCHAR (NCHAR columns are right padded to the column length) as was probably expected.