Re: Character set: moving from WE8ISO8859P1 to UTF8
Date: Tue, 6 May 2008 13:16:49 -0700 (PDT)
On May 6, 6:49 pm, joel garry <joel-ga..._at_home.com> wrote:
> On May 6, 9:52 am, jeremy <jeremy0..._at_gmail.com> wrote:
> > Could anyone point me in the direction of any guides which could
> > advise on the likely steps required to make applications code work on
> > a database created as UTF8 character set versus WE8ISO8859P1 (against
> > which the application was developed and runs in production now)? I am
> > really looking for suggested settings of any NLS parameters that might
> > enable compatibility and a checklist of the things that might need to
> > be reviewed.
> > Appreciate any pointers
> > many thanks
> > jeremy
> There's a lot of little gotchas, which mostly revolve around funny
> things done by apps and misconfigurations. For example, If you've put
> things that aren't in the character set into the db, then use an NLS
> with tools like exp that translates the character set for you, that's
> when data gets messed up.
> There is probably too much documentation on this due to the gazillion
> possibilities. You want to see the globalization support guide in the
> docs, and there are a number of docs on metalink explaining some of
> the possibilities, some of which are out of date or disagree with
> others. In general, you want to set the db to the character set that
> includes all your localizations (as you are doing going to UTF), and
> set each client to their proper local setting. Before you convert,
> there is are scanners you run to see if anything will require special
> Platform and version are very important, as well as your specific app,
> programming environment (seehttp://download.oracle.com/docs/cd/B19306_01/server.102/b14225/ch7pro...
> ) and localizations. In my experience, it seems overwhelmingly
> complex at first, but when you boil it down to specifics the answer is
> usually pretty straightforward.
Thanks for the response. We aren't converting the database as such - we are migrating from 9iR2 on Solaris to 10gR2 on RHEL4 which wil involve an export followed by import.
Of equal concern though is understanding what settings are required in (for our case) the dads.conf file to preserve application behaviour (as ours is an application built using the modplsql).
We already ran across something strange where use of
substr(myvar,1,4000) resulted in a pl/sql numeric or value error as the number of chars returned (or do I mean bytes?) was actually 4001 - and we were trying to populate a pl/sql variable defined as varchar2(4000)... the developer then looked at substrb but I think that this is not the correct answer (though I could be wrong).
-- jeremyReceived on Tue May 06 2008 - 15:16:49 CDT