Page 1 of 1
Posted: Wed May 15, 2013 2:47 am
by sendmkpk
how r these words appearing when viewed in DB2?
what is the source datatype etc?
which country related data is it? did u try that country NLS?
did u try to write to a file and ck?
Posted: Wed May 15, 2013 2:50 am
by chandra.shekhar@tcs.com
You can use double Convert function in transformer, it will remove all the junk characters other than alphabets and numbers.
Posted: Wed May 15, 2013 2:54 am
by chulett
"There is no bad data, only misunderstood data."
I'm sure Ray will be along to have 'the discussion' before too long.
Posted: Wed May 15, 2013 3:20 am
by varsha16785
sendmkpk wrote:how r these words appearing when viewed in DB2? -- In DB2 they are appearing normally, without any of these foreign characters
what is the source datatype etc? -- Soure and Target datatype both are varchar .. it is basically a description field.
which country related data is it? did u try that country NLS? -- This US related data
did u try to write to a file and ck?
-- yes we tried writing to a file and were successful, but our ultimate goal is to write in a table
Posted: Wed May 15, 2013 4:00 am
by ray.wurlod
sendmkpk wrote:how r these words appearing when viewed in DB2?
what is the source datatype etc?
which country related data is it? did u try that country NLS?
did u try to write to a file and ck?
U did not try any of these things, because U is not at the same site as varsh16785.
The second person personal pronoun in English is spelled "you", not "u". The present tense plural of the verb "to be" is spelled "are", not "r".
DSXchange is not a mobile phone. There is no limit of 140 characters per post, and therefore no need at all to use SMS-style abbreviations. We strive for a professional standard of written English, not least because English is not the first language of everyone who reads these posts.
Posted: Wed May 15, 2013 4:03 am
by ray.wurlod
Don't trust how View Data represents non-ASCII characters.
Experiment with text files and hex editors/viewers to learn exactly what these characters are, and then process them accordingly.
There are NO junk characters.
Re: Junk Charachters in datastage
Posted: Fri May 17, 2013 1:44 am
by sreddy666
For 2 nd query.. try this.. apt_string_pad_char(0X20) we had simlar situation seen tiny box symbo, while viewing data from DB2 .. resolved with setting apt_string_pad_char(0X20) .
Re: Junk Charachters in datastage
Posted: Fri May 17, 2013 10:34 am
by priyadarshikunal
sreddy666 wrote:For 2 nd query.. try this.. apt_string_pad_char(0X20) we had simlar situation seen tiny box symbo, while viewing data from DB2 .. resolved with setting apt_string_pad_char(0X20) .
That you get for char data types, if you have 0x0 or some other un-printable character defined as APT_SRTING_PADCHAR, and the char is padded with NULL character or other unprintable character.
Re: Junk Characters in datastage
Posted: Sat May 18, 2013 8:32 pm
by Nsg
I faced similar issue and using Translate in the db2 extarct sql helped. If you query the DB2 with hex(clm_name) it will actauuly show you the hex that needs to be translated.
Let me know if you need exact syntax for these. They can be easily found on net.
- nsg