Lost in Translation

Posted by antony.reynolds on Oracle Blogs See other posts from Oracle Blogs or by antony.reynolds
Published on Wed, 17 Mar 2010 16:10:31 -0700 Indexed on 2010/03/17 23:21 UTC
Read the original article Hit count: 431

Filed under:

Using the Correct Character Set for the SOA Suite Database

A couple of years ago I spent a wonderful week in Tel Aviv helping with the first Oracle BAM implementation in Israel.  Although everyone I interacted spoke better English than I did, the screens and data for the implementation were all in Hebrew, meaning the Hebrew alphabet.  Over the week I learnt to recognize a few Hebrew words, enough to enable me to test what we were doing.  So I knew SOA Suite worked OK with non-English and non-Latin character sets so I was suspicious recently when a customer was having data corruption of non-Latin characters.  On investigation it turned out that the data received correctly in the SOA Suite, but then it was corrupted after being stored in the database.

A little investigation revealed that the customer was using the default database character set, which is “WE8ISO8859P1” which, as the name suggests only supports West European 8-bit characters.  What was happening was that when the customer had installed his SOA repository he had ignored the message that his database was not using AL32UTF as the character.

After changing the character set on his database he no longer saw the corruption of non-English character data.

So the moral of this story is

  • Always install the SOA Repository in to an AL32UTF8 Database
This is true for both SOA Suite 10g and 11g.  Ignore it at your peril, because you never know when you will need to support Hebrew, or Japanese or another multi-byte character set.

© Oracle Blogs or respective owner