|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
 |
|
Oracle error while doing an update |
« View previous topic :: View next topic » |
Author |
Message
|
PBosze |
Posted: Mon Jul 01, 2002 4:14 am Post subject: Oracle error while doing an update |
|
|
 Newbie
Joined: 01 Jul 2002 Posts: 5 Location: Hungary
|
Hi all,
has anyone experienced the following WMQI error?
The MQSI 2.0.2 broker is running on an AIX, with its database on Oracle 8
(both the broker db and the business db are running on ORA).
Sometimes the following error occurs on both the test and the production
machines:
The node is trying to make an update to the database:
----
The broker was unable to receive a 'stopped' publish event response.
ORACLE Native Error Code '1475'; must reparse cursor to change bind variable datatype.
----
It helps if I restart the broker and redeploy the flow, but c'mon, this
cannot be the solution.
This function had worked before. Even yesterday.
Has anyone any idea why it occurs?
Thx.
Peter. _________________ Péter Bősze
Middleware Consultant
e-mail: peter_bosze@msn.com
phone: +36 (70) 561-8571 |
|
Back to top |
|
 |
michaelpatton |
Posted: Mon Jul 01, 2002 6:17 pm Post subject: |
|
|
 Apprentice
Joined: 21 May 2002 Posts: 25 Location: East Coast USA
|
From my understanding, this has to do with the merant odbc driver, and merant is currently testing a fix for it and should be available soon. I believe it is related to trying to insert null fields into the database, and the driver then tries to make that field a SQL_C_DEFAULT type instead of the data type the field was defined with. Sorry, I do not remember the merant problem code for this one. |
|
Back to top |
|
 |
PBosze |
Posted: Mon Jul 01, 2002 11:06 pm Post subject: |
|
|
 Newbie
Joined: 01 Jul 2002 Posts: 5 Location: Hungary
|
Thanks Michael, I haven't heard that a fix is coming.
I did find out the same: it must be an ODBC problem.
That's why restarting the broker and redeploy the flow fix the problem for a while.
I hope the merant fix will come soon. We will see. _________________ Péter Bősze
Middleware Consultant
e-mail: peter_bosze@msn.com
phone: +36 (70) 561-8571 |
|
Back to top |
|
 |
mcatama |
Posted: Mon Nov 11, 2002 4:43 am Post subject: |
|
|
Novice
Joined: 10 Apr 2002 Posts: 17
|
Hi,
Just wondering if anyone has seen a fix for this yet as I am experiencing the same problem.
Thanks,
Alison |
|
Back to top |
|
 |
mcatama |
Posted: Thu Mar 27, 2003 6:04 am Post subject: |
|
|
Novice
Joined: 10 Apr 2002 Posts: 17
|
For the benefit of anyone who experience a similar problem to this, the problem I experienced was due to the way WMQI binds variables to an SQL statement as a specific datatype and then caches the statement.
The first time our pSQL statement was called one of the parameter values was passed from a variable of type INTEGER. The seond time it was called it the parameter value was passed from a value in the RFH2 header which WMQI interprets as a string. Because the SQL statement had been cached after the first call it was expecting a number for the parameter and therefore failed on the second call because a string was passed. This was resolved by expliclty casting the parameter value to be an integer.
The more coherent explanation from IBM support was:
"The first time WMQI executes this SQL statement it prepares the SQL
statement and caches it. Then the input parameters (values) are bound
to this cached SQL statement. This will be done with the datatype of
the data provided in the input parameters. In the customers case, the
first time this SQL statement is executed the source of the data for
the input parameter is numeric (and therefore bound as SQL_C_LONG).
On the processing of a subsequent message the source of the data for
the input parameter is from the RFH2 header folder and here
WMQI interprets the data as string and therefore tries to bind the
input parameter as SQL_C_CHAR which then fails with a "ORA-01475: must
reparse cursor to change bind variable datatype" error.
The customer has resolved this by casting the input parameters to
INTEGER before the database call, thereby ensuring a constant datatype
is passed each time for this input parameter. "
Alison |
|
Back to top |
|
 |
|
|
 |
|
Page 1 of 1 |
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|
|
|