DSXchange

Hi,

I have a datastage job in which the source and target are defined as varchar,but while inserting into the database where the column is defined as 50, i see ^z (ascii 32) being inserted into the table.

if input is say "abc" in the database i see abc padded with ^z till 50 bytes. it appears as a white space,but its actually ^z.

I have replaced the database stage(oracle enterprise) with a peak to see the value. its fine in the peak.

any idea?

pavankvk wrote:Hi,

I have a datastage job in which the source and target are defined as varchar,but while inserting into the database where the column is defined as 50, i see ^z (ascii 32) being inserted into the table.

if input is say "abc" in the database i see abc padded with ^z till 50 bytes. it appears as a white space,but its actually ^z.

I have replaced the database stage(oracle enterprise) with a peak to see the value. its fine in the peak.

any idea?

I verified the input and there are no ^z from the source. even in the intermediate stages, i verified it with peak,but i see them on the database.

APT_STRING_PAD_CHAR

ArndW wrote:APT_STRING_PAD_CHAR ...

its a single space. when its a varchar, how does this matter?

What load method are you using and are these VarChar2 columns?

ArndW wrote:What load method are you using and are these VarChar2 columns? ...

Using an Upsert mode with a user defined update only. i have a insert statement instead of update. all columns are varchar2.

with in the oracle stage, in the insert statement if i use trim(orchestrate.column), i dont see these characters though. but i dont want to do that..

ArndW wrote:What load method are you using and are these VarChar2 columns? ...

Using an Upsert mode with a user defined update only. i have a insert statement instead of update. all columns are varchar2.

with in the oracle stage, in the insert statement if i use trim(orchestrate.column), i dont see these characters though. but i dont want to do that..

That means somewhere in your job you are converting from a fixed length CHAR field to a VarChar and are getting those ^Zs

ArndW wrote:That means somewhere in your job you are converting from a fixed length CHAR field to a VarChar and are getting those ^Zs ...

I checked all the stages, from source to target, i dont see any char..each and every stage its defined as varchar

pavankvk wrote:

ArndW wrote:That means somewhere in your job you are converting from a fixed length CHAR field to a VarChar and are getting those ^Zs ...

I checked all the stages, from source to target, i dont see any char..each and every stage its defined as varchar

Also, if i USE a Load option instead or regular insert, i dont see those characters. its happening only for a insert.

Does any sequential file stage in your job specify DOS-style line terminators, or process a file that was created in a Windows environment?

Ctrl-Z is the Windows end-of-file marker character.

I was going to mention that, but they stated they didn't just see one but rather it was coming in as the 'pad' character in varchar fields from some reason.