Problem with JOIN stage

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
Sravani
Participant
Posts: 23
Joined: Thu Jun 15, 2006 3:56 am
Location: Hyderabad

Problem with JOIN stage

Post by Sravani »

Hi all,

We are using a JOIN stage with the inner join on a double column. Both the inputs that are coming to the JOIN stage are having hte one matched value but the output I am getting is nothing. But when I just replaced the JOIN stage with the LOOKUP stage it is working fine without any other change.

Can anybody tell me why this JOIN stage is not working whre as LOOKUP is working with the same data.

Thanks in advance,
Sravani.
Sravani
kiran259
Participant
Posts: 48
Joined: Thu Aug 16, 2007 11:17 pm
Location: United States
Contact:

Post by kiran259 »

Comparison will be done on equality basis,actually there should not be a problem as both stages will compare the records.Some more information is needed to justify.
Kiran Vaduguri

As soon as the fear approaches near, attack and destroy it.
Sravani
Participant
Posts: 23
Joined: Thu Jun 15, 2006 3:56 am
Location: Hyderabad

Post by Sravani »

Hi Kiran,

Thanks for your response on my problem. Please see the problem details below.
1) I am getting the record count using aggregator stage from 2 types of input.
2) 1st input(sequectial file) using aggregator is giving the record count 872759
3) 2nd input(sequectial file) using aggregator is giving the record count 872759 only
4) These two values are being compared using the JOIN stage, with Inner join property and expecting the output should be is giving the count 872759 written to a sequential file in case both the values are same.
But this is not happening. It is writing nothing to the sequential file.

Note: I have verified the two record counts by writting them to different sequential files and ensured that the count is same from both the links.

For time being we have rectified this by replacing the LOOKUP stage which does the same thing. But I would like to know why the JOIN stage is not working properly.

Request to please solve my issue if anyone of you has faced this problem earlier in Information Server.
Sravani
ray.wurlod
Participant
Posts: 54607
Joined: Wed Oct 23, 2002 10:52 pm
Location: Sydney, Australia
Contact:

Post by ray.wurlod »

Can you please sketch out your job design? Can you use Copy or inline Peek stages and capture the output of each Aggregator for diagnostic purposes?
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
Sravani
Participant
Posts: 23
Joined: Thu Jun 15, 2006 3:56 am
Location: Hyderabad

Post by Sravani »

Hi Ray,

I/P File1-->TRANSFORMER--->AGGREGATOR--->COPY --->O/P1
> JOIN--->O/Pfinal
I/P File2-->TRANSFORMER--->AGGREGATOR--->COPY --->O/P2

In the above structure, I am verifying the o/p of two COPY stages which are being joined. Both the OP1 and OP2 are giving the same value(872759) as I mentioned as a NOTE, in my previous mail. But the O/Pfinal is NULL where as it should write the matched valued to the output.

But when I replace the JOIN stage with LOOKUP stage, it is writing the required o/p to the O/Pfinal.

I/P File1-->TRANSFORMER-->AGGREGATOR-->COPY --->O/P1
> LOOKUP--->O/Pfinal
I/P File2-->TRANSFORMER-->AGGREGATOR-->COPY --->O/P2

I am still not understanding why the JOIN stage is behaving strangely.

Looking for help.
Sravani
pksahu
Participant
Posts: 29
Joined: Wed Jul 25, 2007 5:07 am

Post by pksahu »

Can you verify both datatype from the Aggregator output? Both should be same for a match.

-pksahu

[quote="Sravani"]Hi Ray,

I/P File1-->TRANSFORMER--->AGGREGATOR--->COPY --->O/P1
> [b]JOIN[/b]--->O/Pfinal
I/P File2-->TRANSFORMER--->AGGREGATOR--->COPY --->O/P2

In the above structure, I am verifying the o/p of two COPY stages which are being joined. Both the OP1 and OP2 are giving the same value(872759) as I mentioned as a NOTE, in my previous mail. But the O/Pfinal is NULL where as it should write the matched valued to the output.

But when I replace the JOIN stage with LOOKUP stage, it is writing the required o/p to the O/Pfinal.

I/P File1-->TRANSFORMER-->AGGREGATOR-->COPY --->O/P1
> [b]LOOKUP[/b]--->O/Pfinal
I/P File2-->TRANSFORMER-->AGGREGATOR-->COPY --->O/P2

I am still not understanding why the JOIN stage is behaving strangely.

Looking for help.[/quote]
pksahu
Participant
Posts: 29
Joined: Wed Jul 25, 2007 5:07 am

Post by pksahu »

Can you verify both datatype from the Aggregator output? Both should be same for a match.

-pksahu

[quote="Sravani"]Hi Ray,

I/P File1-->TRANSFORMER--->AGGREGATOR--->COPY --->O/P1
> [b]JOIN[/b]--->O/Pfinal
I/P File2-->TRANSFORMER--->AGGREGATOR--->COPY --->O/P2

In the above structure, I am verifying the o/p of two COPY stages which are being joined. Both the OP1 and OP2 are giving the same value(872759) as I mentioned as a NOTE, in my previous mail. But the O/Pfinal is NULL where as it should write the matched valued to the output.

But when I replace the JOIN stage with LOOKUP stage, it is writing the required o/p to the O/Pfinal.

I/P File1-->TRANSFORMER-->AGGREGATOR-->COPY --->O/P1
> [b]LOOKUP[/b]--->O/Pfinal
I/P File2-->TRANSFORMER-->AGGREGATOR-->COPY --->O/P2

I am still not understanding why the JOIN stage is behaving strangely.

Looking for help.[/quote]
Vinodanand
Premium Member
Premium Member
Posts: 112
Joined: Mon Jul 11, 2005 7:54 am

Post by Vinodanand »

Hi,
Can you check the dataypes that was specified, just to make sure. I tried to mimic the same scenario and worked for me without any issues.
Regards,
Vinod
Sravani
Participant
Posts: 23
Joined: Thu Jun 15, 2006 3:56 am
Location: Hyderabad

Post by Sravani »

Hi,

Both the datatypes are same ie; Integer (11).

Thanks,
Sravani
John Smith
Charter Member
Charter Member
Posts: 193
Joined: Tue Sep 05, 2006 8:01 pm
Location: Australia

Post by John Smith »

Did you hash partitioned your data? Your lookup could have the entire file hashed so that would work.
just my 2 cents.
Post Reply