Author |
Message
|
amardesai16 |
Posted: Thu Jul 18, 2013 5:38 am Post subject: Issue while fetching special characters from Informix DB |
|
|
Newbie
Joined: 29 Jun 2012 Posts: 4
|
Getting Unconvertable character error while running the select query on the Informix Database from Message Broker.
We have a message flow which runs on the multi instance Message broker environment. This message flow receives a SOAP request from client application and then connects to the Informix Database and fires a select query to retrieve data from the database and then sends the response back to the client application.
Currently when message flow tries to retrieve data from informix database through a select query we are getting Unconvertable character error. We investigated and found out that one of the columns of the database which we are trying to fetch has special character of registered Trademark "®" which is causing this error, because when we ignore this particular column we are not getting any errors and applications works fine.
Also the above behavior is not consistent. Sometime the application works fine without any issues when we restart message broker and queue manager number of times. Then again when application is working fine if message broker gets restarted its stops working and gives us the same error as described above.
This applications works fine in all our lower environments like DEV & SIT. We encountered this issue only in our UAT environment. The difference between DIT/SIT & UAT environment is in DIT/SIT we do not have multi instance message broker w, while in UAT we have multi instance message broker.
Please find below the MQ & Message Broker UAT environment details for your reference
Multi Instance Queue Manager
MQ Version: 7.0.1.8
Multi Instance Message Broker
Message Broker Version : 7.0.0.4
Database: Informix 11.x
Appreciate a quick response  |
|
Back to top |
|
 |
smdavies99 |
Posted: Thu Jul 18, 2013 5:46 am Post subject: |
|
|
 Jedi Council
Joined: 10 Feb 2003 Posts: 6076 Location: Somewhere over the Rainbow this side of Never-never land.
|
Does it always happen on the same host? Or does it not matter which instance of the QMGR you are using?
What platform are you running on? _________________ WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
Back to top |
|
 |
lancelotlinc |
Posted: Thu Jul 18, 2013 5:53 am Post subject: |
|
|
 Jedi Knight
Joined: 22 Mar 2010 Posts: 4941 Location: Bloomington, IL USA
|
|
Back to top |
|
 |
amardesai16 |
Posted: Thu Jul 18, 2013 5:57 am Post subject: |
|
|
Newbie
Joined: 29 Jun 2012 Posts: 4
|
We are using Linux suse 11
There is no consistency sometime it works on both nodes and sometime it doesnt |
|
Back to top |
|
 |
amardesai16 |
Posted: Thu Jul 18, 2013 5:59 am Post subject: |
|
|
Newbie
Joined: 29 Jun 2012 Posts: 4
|
I can handle this error but we want to process those special characters that are coming from database. As they are required to be sent back in the respposne |
|
Back to top |
|
 |
fatherjack |
Posted: Thu Jul 18, 2013 6:11 am Post subject: |
|
|
 Knight
Joined: 14 Apr 2010 Posts: 522 Location: Craggy Island
|
amardesai16 wrote: |
There is no consistency sometime it works on both nodes and sometime it doesnt |
So what makes you sure it is the special characters that are causing the problem? _________________ Never let the facts get in the way of a good theory. |
|
Back to top |
|
 |
kimbert |
Posted: Thu Jul 18, 2013 6:44 am Post subject: |
|
|
 Jedi Council
Joined: 29 Jul 2003 Posts: 5542 Location: Southampton
|
Quote: |
Currently when message flow tries to retrieve data from informix database through a select query we are getting Unconvertable character error. We investigated and found out that one of the columns of the database which we are trying to fetch has special character of registered Trademark "®" which is causing this error, because when we ignore this particular column we are not getting any errors and applications works fine. |
So you have a smoking gun, but you have not yet proved the case.
You need to find out what the target encoding ( the CCSID ) was. Where did that encoding come from? Who set it to that value?
Presumably, when the flow works correctly, that CCSID is set to some other value. What is that other value? ( user trace could probably tell you ). Can you come up with a plausible reason why the CCSID might change? |
|
Back to top |
|
 |
amardesai16 |
Posted: Thu Jul 18, 2013 11:35 am Post subject: |
|
|
Newbie
Joined: 29 Jun 2012 Posts: 4
|
We removed that special character from the database column and then tried to retrieve it and it works fine without issues. The problem comes only when that particular column has registered trademark symbol in it. |
|
Back to top |
|
 |
smdavies99 |
Posted: Thu Jul 18, 2013 10:19 pm Post subject: |
|
|
 Jedi Council
Joined: 10 Feb 2003 Posts: 6076 Location: Somewhere over the Rainbow this side of Never-never land.
|
What application was use to enter (insert or update) the column with the trademark symbol in it?
Perhaps it was using an incorrect CCSID?
As kimbert says, this is a smoking gun. someone somewhere is doing something that is effectively the first 'GI' in GIGO.
Go backwards and find out who is responsible and GET THEM TO CHANGE THEIR APPLICATION. _________________ WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
Back to top |
|
 |
kimbert |
Posted: Fri Jul 19, 2013 12:50 am Post subject: |
|
|
 Jedi Council
Joined: 29 Jul 2003 Posts: 5542 Location: Southampton
|
I noticed this in the OP's original problem statement:
Quote: |
Also the above behavior is not consistent. Sometime the application works fine without any issues when we restart message broker and queue manager number of times. Then again when application is working fine if message broker gets restarted its stops working and gives us the same error as described above. |
If true, it sounds like something more than a simple functional problem in the sending application. But the only way to diagnose it is to start digging deeper - as suggested earlier in this thread. |
|
Back to top |
|
 |
|