Hi all,
In one of my requirements i need to use the @INROWNUM function.When i was trying to use that, the job was working fine.But all the records were dropping.
I was giving a constraint @INROWNUM > 1.
I had to read from the second record.
Where as, it was working fine in the server jobs..What might be the possible reason for this...
@INROWNUM Problem
Moderators: chulett, rschirm, roy
@INROWNUM Problem
Thanks and Regards!!
dspxlearn
dspxlearn
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
The only reason for this is that the variable is not available in parallel jobs. If it were it could only mean "the row number on this processing node" - for N processing nodes there would be N instances of row #1.
You need a better strategy in parallel execution - there are a few from which to select, but pre-processing the file would be my recommendation.
You need a better strategy in parallel execution - there are a few from which to select, but pre-processing the file would be my recommendation.
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
-
- Participant
- Posts: 36
- Joined: Thu Sep 01, 2005 5:44 am
- Location: Canada
What is the alternative for @INROWNUM in Parallel jobs
If @INROWNUM variable doesn't work in PX, then what is the work around available to achieve this?ray.wurlod wrote:The only reason for this is that the variable is not available in parallel jobs. If it were it could only mean "the row number on this processing node" - for N processing nodes there would be N instan ...
I tried to achieve this by using a transformer stage and making it to execute in sequential mode. Still it's not working. The @INROWNUM is giving values as 1,2,10,11,12........
instead of 1,2,3,4.........
Thanks
Rony
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
Unless your stage is operating in sequential mode (which rather defeats the purpose of having parallel jobs), you are generating multiple streams of values. If you need a strategy for generating unique numbers across all streams, try a cycle beginning with the partition number and incrementing by the number of partitions. Thus, for example with four partitions, the first partition will have 0, 4, 8, 12, ..., the second partition will have 1, 5, 9, 13, ..., the third partition will have 2, 6, 10, 14, ..., and the fourth partition will have 3, 7, 11, 15, ...
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.