|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
 |
|
Conversion between Broker, ODBC Driver and Database |
« View previous topic :: View next topic » |
Author |
Message
|
Luke |
Posted: Fri Aug 14, 2009 3:26 am Post subject: Conversion between Broker, ODBC Driver and Database |
|
|
Centurion
Joined: 10 Nov 2008 Posts: 128 Location: UK
|
Hi,
First a disclaimer - I'm aware that several similar types of queries have been raised recently, I've read all of them, and some of the additional reading posted by Kimbert. I've also Googled and searched ibm.com and here ...
I believe I have a decent understanding of codepages, and I'm reasonably familiar with conversion via MQ. However, I'm struggling to find any documentation that explains explicitly what conversion occurs (or what determines the conversion that occurs) between my ESQL in a compute node, the odbc driver and the target database when I insert a row (doing this via a PASSTHRU).
The particular data that is causing me problems is cyrillic characters, and comes in to the flow via MQ with a CCSID of 1208. I've stopped the message on the queue and confirmed this CCSID, I've also confirmed the hex is correct for that CCSID. Convert option is not checked on MQInput node.
I'd really like to understand what happens when the string in question is passed to the odbc driver, I'm guessing something like:
1) Internally, Broker converts the string from 1208 to internal UCS-2.
2) Does it then pass the string to the odbc driver in UCS-2? Or is there another conversion at this stage to a local CCSID? If so, which language/region settings on Windows determine the local CCSID that Broker converts to?
3) Somewhere between the odbc driver and the DB, the data is converted to the codepage of the DB - in this case my Oracle DB has CL8MSWIN1251.
Any kind of clarification of my understanding, or a point towards some documentation would be much appreciated. I'm currently getting squares where I should have cyrillic data on the DB.
Thanks
Luke
Details:
MQ 6.0
WMB 6.1
DB - Oracle 10g
odbc - MQSeries DataDirect 5.3 32 bit Oracle
Platform - Windows XP / Windows Server 2003 (XP just for unit testing) |
|
Back to top |
|
 |
mqjeff |
Posted: Fri Aug 14, 2009 3:44 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 17447
|
It is my guess that the data conversion happens inside the ODBC driver, or inside the database.
My best guess as to how you can magically solve your problem, and this is based on experience, is to ensure that your *database* actually has a proper national language environment configured in it's shell/startup environment.
Oracle should have some documentation on how it does NLS conversion, you might review this.
Also, of course, you should make very very sure that the Cyrillic characters you have at start are actually valid 1208 characters, and that there is a valid set of codepage conversions for them to the destination CL8MSWIN1251. |
|
Back to top |
|
 |
Luke |
Posted: Mon Aug 17, 2009 6:32 am Post subject: |
|
|
Centurion
Joined: 10 Nov 2008 Posts: 128 Location: UK
|
Thanks for your thoughts on this mqjeff. Your guesses sound more than reasonable, and once I get my test environment rebuilt, I'll double check the things you suggested again.
I had a look at NLS conversion documentation - this focused on Oracle client conversions, where the NLS_LANG of the client compared to the codepage of the database determines the conversion that takes place. I'd guess the odbc connection works in a similar way, but not sure what the driver uses to determine the codepage of data coming from the broker.
I still feel like we're guessing though, and I'd like to understand it, so if anyone can point me towards some documentation it would be much appreciated ... I had a look for a redbook that might cover it, but was struggling to find something suitable. Any suggestions?
Thanks
Luke |
|
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
|
|
|
|