literal spaces treated as a key

Post questions here relative to DataStage Enterprise/PX Edition for such areas as Parallel job design, Parallel datasets, BuildOps, Wrappers, etc.

Moderators: chulett, rschirm, roy

Post Reply
travissolt
Participant
Posts: 51
Joined: Mon Feb 05, 2007 1:53 pm

literal spaces treated as a key

Post by travissolt »

The system we are acessing is old and allows literal spaces ' ' as part of the key on some of their tables. During the change data capture it works fine because it compares a null to a null and finds no difference. However when it goes to load the changes into the final table it will not allow the NULL value to be loaded (even though it is really ' ' in the oracle table). I know that I can manipulate the data upfront but we are supposed to pass the data forward as is and I am wondering if datastage can be modified to accept literal spaces.

The below code snippet came out of the unix ctl log for the job. The PANEL field is the one in question (it can contain values of ' '). I can tell that for other nullable fields (such as CONTRACTTYPE below) that if it is blank datastage will bring it in as NULL. Is it safe to say the same thing will happen for my PANEL field even though it is not spelled out. Could this be modified?

PANEL POSITION(46:54) ,
CONTRACTTYPE POSITION(108:110) NULLIF CONTRACTTYPE =BLANKS,

Thanks
kumar_s
Charter Member
Charter Member
Posts: 5245
Joined: Thu Jun 16, 2005 11:00 pm

Post by kumar_s »

Btw, space is not NULL. Where do you find the space character is getting changed as Null? Is the field a Varchar datatype?
Impossible doesn't mean 'it is not possible' actually means... 'NOBODY HAS DONE IT SO FAR'
chulett
Charter Member
Charter Member
Posts: 43085
Joined: Tue Nov 12, 2002 4:34 pm
Location: Denver, CO

Post by chulett »

Isn't there some kind of equivalent to sqlldr's PRESERVE_BLANKS setting? Otherwise, spaces get trimmed and you can end up with a null field. Assuming we're talking Oracle here.
-craig

"You can never have too many knives" -- Logan Nine Fingers
travissolt
Participant
Posts: 51
Joined: Mon Feb 05, 2007 1:53 pm

Post by travissolt »

Im not saying that the space is a null its a really 3 spaces in a varchar2(9) datatype. Somewhere in datastage it is converting the spaces to nulls during the parallel job. After a change data capture it tries to insert null values into the change table when really it should be trying to insert the ' ' as the key value. The job bombs out and gives me an error that datastage cannot insert null into a key field. For right now I have it fixed in that I am changing the null to '0' using the ISNULL function but my audit log now has the key field as a '0' as opposed to the ' '. I am sure it will work.....but if they want to retain the values in the source system I am wondering if there is away to keep the field as spaces.
ray.wurlod
Participant
Posts: 54607
Joined: Wed Oct 23, 2002 10:52 pm
Location: Sydney, Australia
Contact:

Post by ray.wurlod »

Set APT_STRING_PADCHAR to space (\x20) rather than to NUL (\x00).
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
travissolt
Participant
Posts: 51
Joined: Mon Feb 05, 2007 1:53 pm

Post by travissolt »

Is that something I will need to get the datastage admin to change or can I bring it in as a parameter and change it. When i bring APT_STRING_PADCHAR in as an environment variable it has 0x0 as the default. My guess is 2x0 for the relacement.
kumar_s
Charter Member
Charter Member
Posts: 5245
Joined: Thu Jun 16, 2005 11:00 pm

Post by kumar_s »

Changing in Adminstrator will affect your whole project. Sourcing that variable in your job and assigining a different variable will affect only that particular job. You need to decide on how it should reflect. In the variable, you can simple give a space ' ' rather than giving it in Hex value.
Impossible doesn't mean 'it is not possible' actually means... 'NOBODY HAS DONE IT SO FAR'
ray.wurlod
Participant
Posts: 54607
Joined: Wed Oct 23, 2002 10:52 pm
Location: Sydney, Australia
Contact:

Post by ray.wurlod »

Not 2x0, but rather 0x20 if you're going to use the hex representation.
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
travissolt
Participant
Posts: 51
Joined: Mon Feb 05, 2007 1:53 pm

Post by travissolt »

I used $APT_ORACLE_PRESERVE_BLANKS set to True as a parameter at the job level and it has worked so far. Thanks
travissolt
Participant
Posts: 51
Joined: Mon Feb 05, 2007 1:53 pm

Post by travissolt »

The $APT_ORACLE_PRESERVE_BLANKS works but unfortunatley it pads all spaces for all fields. So if a field had 36 characters and only used 10 the parallel job brings in all 36 (the 10 plus the 26 spaces). Basically it will not work. For now we have decided to default all literal spaces to '0' and just relay the message to the user community.
travissolt
Participant
Posts: 51
Joined: Mon Feb 05, 2007 1:53 pm

Post by travissolt »

Ok I just want to get the right resolution out here in case someone has the same issue. The literal spaces come into datastage fine and can flow through a transformation,lookup or filter as in our flow. The problem shows up in the final load to the oracle table. In our process we were using the LOAD option which apparently uses a datastage ORACLE SQL loader process and within that process of datastage it has the statement NULLIF 'FIELDNAME' =BLANKS. If we change the final load option to UPSERT then the key_ID containing the ' ' spaces can still be inserted as a field and the null issue goes away. Thought I would let you know our final resolution. So if you have source systems that have spaces as key fields you will need to use the upsert option when finally loading to an oracl table.
Thanks
Post Reply