DSXchange

Not necessarily an NLS issue, at least not yet. Any chance you are moving any kind of "LOB" data in the job? It is not supported and can generate that error, hence the question.

In source data type for this column is varchar2(240)... Not "LOB". Also I have tried with LongVarchar data type but same error.

userasif wrote:...If I use NONE for NLS Mapping for source stage then job finished is OK but data is not in Arabic form...

Just to be certain, how do you determine that the output isn't correct? Do not use the "view data" functionality to do this.

ArndW, I am not using "View data" functionality but in SQL Plus also it shows "???????????" for this data. The same data in other application is in Arabic form.

Best use a tool which shows you the hex values for each character. "?" could be either a real question mark or it could mean an undisplayable character (using the session's NLS settings). What is the HEX or Decimal value of the first '?' character in the string?

Invalid handle usually indicates some kind of connectivity problem, rather than any kind of data problem.

That said, I will almost guarantee that you can not use a Russian map to move Arabic data.

Character maps do NOT perform translation!

The HEX value for first ? is 203F. Also this is the same HEX value for this data in source database. English data in source db is fine but Arabic data in source db is like '????". My concern is to get these question marks to be translated in Arbaic because these are Arabic data.

And what value was that character (again in HEX) in the source?

0x20 3F isUndertie in Unicode.

As Ray has already stated, are you sure that your selected character sets are correct? Is the arabic data in your source perhaps already stored correctly and by trying to convert from Russian to Arabic you are actually corrrupting the data?

Are you sure that your selected character sets are correct?
I am not sure about the Russian character set to be used in DataStage but I am using KOI8-R.
Also problem occurs with input stage NLS Mapping.
Is the arabic data in your source perhaps already stored correctly?
Yes, because the same source data display is in Arabic in Oracle Forms application.

Since RU8PC866 does not contain mappings for arabic characters but you stated that they are visible in the source, you are essentially corrupting your data by mapping it from KOI8-R during your initial read. This stage needs to be told that the incoming data is already in AR8MSWIN1256

I have tried it with MS1256 but same error. Also I have tried with UTF-8 and ohter as an hit and trial method but same error for all NLS Map selection except NONE.

I think you are trying too much at once. Reduce the problem to the read portion, just read the data and then write to a sequential file. Ensure you choose the right mapping for your source - once that works, you can add complexity.

ArndW sorry... Following error when output is Sequential File.
"Attempting to Cleanup after ABORT raised in stage".
Also with NONE NLS Map in Source stage...job is sucessful but data is written in question marks "?????" to text file. I have changed the text file to UTF-8 but same "?????????????"

Remember that a "?" mark might be an undisplayable character, so you will need to produce the hex equivalent. Start with the source - what is the hex value of the first character. Then check the same character in the sequential file. If you maps are NONE then they will be identical. If both your source and target maps are arabic, the values should be the same as well.