SEO

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

On May 6, 9:52*am, jeremy <jeremy0...@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
treatment.

Platform and version are very important, as well as your specific app,
programming environment (see
http://download.oracle.com/docs/cd/B...e.htm#g1022957
) 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.

jg
--
@home.com is bogus.
Until they steal your servers. http://petergabriel.com/

On May 6, 6:49 pm, joel garry <joel-ga...@home.com> wrote:
> On May 6, 9:52 am, jeremy <jeremy0...@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
> treatment.
>
> 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).

Thanks

--
jeremy

jeremy <jeremy0505@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.

The two things that come to my mind at first are:

1.) Alter all table columns that were created as CHAR(n) or VARCHAR2(n)
to CHAR(n CHAR) and VARCHAR2(n CHAR), respectively.
Otherwise you may find that you sometimes cannot store three letters
in a CHAR(3) column.

2.) Set the client character set correctly (i.e. to the encoding that your
application expects) in NLS_LANG.

It is a common mistake to assume that the client character set should
always be set to the same value as the database character set.

Yours,
Laurenz Albe

jeremy wrote:

>
> 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).

Realize that those symptoms will cascase through all of your
application! Suddenly, columns aren't wide enough, PL/SQL will
break, etc, etc.

BTDT - FvB