Search code examples
unicodeinformatica-powercentercodepagesnls-lang

Incorrect Special Character Handling in Informatica Powercenter 9.1

I am currently working on a project in my organisation where we are migrating Informatica Powercenter in our application from v8.1 to v9.1.

Informatica PC is loading data from datafiles but is not able to maintain certain special characters present in few of the input dat files.

The data was is getting loaded correctly in v8.1.

Tried changing characterset settings in Informatica as below -

CodePage movement = Unicode
NLS_LANG = AMERICAN_AMERICA.UTF8 to ENGLISH_UNITEDKINGDOM.UTF8
"DataMovementMode" = Unicode

After making the above settings I am getting the below error in the in Informatica log:

READER_1_2_1> FR_3015 Warning! Row [2258], field [exDestination]: Data [TO] was truncated. 
READER_1_2_1> FR_3015 Warning! Row [2265], field [exDestination]: Data [IOMR] was truncated. 
READER_1_2_1> FR_3015 Warning! Row [2265], field [parentOID]: Data [O-MS1109ZTRD00:esm4:iomr-2_20040510_0_0] was truncated. 
READER_1_2_1> FR_3015 Warning! Row [2268], field [exDestination]: Data [IOMR] was truncated.

The special character that are being sent in the data are and not being handled correctly -

Ø
Ù
Ɨ
¿
Á

Can somebody please guide how to resolve this issue? What else is required at Informatica end to be changed. Does it need any session parameters to be set in database?

Solution

  • I posted this in another thread about special characters. Please check if this is of any help.

    1. Start with the Source in designer. Are you able to see the data correctly in the source qualifier preview? If not, you might want to set ff source definition encoding to UTF-8.
    2. The Integration service should be running in Unicode mode and not ASCII mode. You can check this from the Integration service properties in Admin Console. The target should be UTF-8 encoding.
    3. Check the relational connection ( if the target is a database) encoding in workflow manager to ensure it is UTF-8
    4. If the problem persists, write the output to a UTF-8 flat file and check if the data is loading properly. If yes, then the issue is with writing to the database.
    5. Check the database settings like NLS_LANG, NLS_CHARACTERSET (for oracle) etc.