Date columns in parallel job behaving peculiarly

A forum for discussing DataStage<sup>®</sup> basics. If you're not sure where your question goes, start here.

Moderators: chulett, rschirm, roy

Post Reply
srilaxmi
Participant
Posts: 22
Joined: Thu Feb 28, 2008 5:21 am

Date columns in parallel job behaving peculiarly

Post by srilaxmi »

Hi,
I have a parallel job that is reading data from SQL server table and loading into a oracle table. There are 7 to 8 date columns in both source and target tables.
Transformer is just a plain one to one mapping.
The problem is whenever I run this job in production environment, one or the other date columns is populated as null values, even though the source SQL table has data for all the date columns.
This job completes successfully without throwing any warnings and when I verify data by querying database I see nulls.
When I run this job from development env it works fine and all date columns show data.
Can somebody help me solve this issue?
Thanks,
Srilaxmi.
ArndW
Participant
Posts: 16318
Joined: Tue Nov 16, 2004 9:08 am
Location: Germany
Contact:

Post by ArndW »

I'm not sure I follow your description corerctly, but would recommend adding a second output from your transform stage to a peek stage so that you can determine if the erroneous null values happen when reading from SQL server into DataStage or when writing to Oracle.
vinnz
Participant
Posts: 92
Joined: Tue Feb 17, 2004 9:23 pm

Re: Date columns in parallel job behaving peculiarly

Post by vinnz »

srilaxmi wrote:The problem is whenever I run this job in production environment, one or the other date columns is populated as null values, even though the source SQL table has data for all the date columns.
What are some of the values being dropped? Is the complete record being dropped or just the column value? Does your job work properly on your Development environment if the same values are in the source table?
srilaxmi
Participant
Posts: 22
Joined: Thu Feb 28, 2008 5:21 am

Post by srilaxmi »

Any one of the date column(complete column for all records) is being populated as NULL, for each run in production.

I have executed the same job in Develpement with the same source table and all the date columns populated properly.
Sri
ray.wurlod
Participant
Posts: 54607
Joined: Wed Oct 23, 2002 10:52 pm
Location: Sydney, Australia
Contact:

Post by ray.wurlod »

Any one or every one? Randomly/intermittently, for every row, or for something for which you can discern a pattern? Are your dates using the default date format?

That's just a few of the things that a systematic diagnosis might investigate.
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
vinnz
Participant
Posts: 92
Joined: Tue Feb 17, 2004 9:23 pm

Post by vinnz »

Any metadata differences between the column(s) being dropped and the ones that are not? Are the rest of the columns getting the right values or are they getting skewed/mis-mapped? Do you have any message handlers defined in your production environment?
vkhandel
Participant
Posts: 35
Joined: Wed Oct 04, 2006 12:12 am
Location: Pune

Post by vkhandel »

I would suggest you to read DATE columns as VARCHAR (SQL Server stores date values in default format "%dd-%mm-%yyyy"), convert them in date using transformer and then load in ORACLE.
Sreenivasulu
Premium Member
Premium Member
Posts: 892
Joined: Thu Oct 16, 2003 5:18 am

Post by Sreenivasulu »

What 'vkhandel' says is apt. You need to take all data columns as varchar.
Since the date format setting in Database and Datastage could be different.


Regards
Sreeni
priyadarshikunal
Premium Member
Premium Member
Posts: 1735
Joined: Thu Mar 01, 2007 5:44 am
Location: Troy, MI

Post by priyadarshikunal »

you should not be worried about date format in different databases and also you don't have to read it as varchar.

Check the warnings in that job.

are you using basic transformer in the job?
Priyadarshi Kunal

Genius may have its limitations, but stupidity is not thus handicapped. :wink:
Post Reply