Incorrect migration of non-ascii/extended-ascii characters

chulett · Post by **chulett** » Mon May 04, 2009 9:37 pm

Define 'migration' and let us know what the NLS characterset is for both the source and the target.

ray.wurlod · Post by **ray.wurlod** » Mon May 04, 2009 11:51 pm

NLS not installed.

But do let us know whether the data are in files, database tables or something else.

chulett · Post by **chulett** » Tue May 05, 2009 5:38 am

ray.wurlod wrote:NLS not installed.

Right, but still would be good to know the characterset in use in both the source and target as you can still accomplish much by correctly setting NLS_LANG and perhaps LC_CTYPE in the job's environment.

Both source and target seem to be Oracle databases, unless they are landed during the 'migration'.

psluser · Post by **psluser** » Fri May 08, 2009 11:44 am

Thanks,

Setting NLS_LANG to AMERICAN_AMERICA.AL32UTF8 did the trick. Even though we have database set up in WE8ISO8859P1.

hsahay · Post by **hsahay** » Fri Jan 31, 2014 3:38 pm

Hi psluser

Can you please clarify exactly where you set the NLS_LANG to AMERICAN_AMERICA.AL32UTF8

chulett · Post by **chulett** » Fri Jan 31, 2014 4:17 pm

In their dsenv file I would imagine. Or you could define it in the Project as user-defined with a value of $ENV and then override it in a specific job, if that's the only place it is needed.