Duplicate INROWNUM

htrisakti3 · Post by **htrisakti3** » Wed Dec 07, 2005 12:31 am

I ran into several occurence where @INROWNUM yields duplicate numbers -- I was wondering if this is known issue
& how does this happen ?? -- thanks, HandyT

ArndW · Post by **ArndW** » Wed Dec 07, 2005 1:40 am

I would look elsewhere before assuming that the @INROWNUM builtin transform value is not functioning correctly. Could you perhaps explain a bit how your job looks and how you determined that this error was happening?

ray.wurlod · Post by **ray.wurlod** » Wed Dec 07, 2005 2:06 am

@INROWNUM is a system variable that records the number of rows received on the stream input link. Since there is only one stream input link it is simply impossible that @INROWNUM can contain duplicate values.

Of course a design can use that value more than once, for example direct it onto more than one output. That is not the same thing as alleging that the system variable is delivering duplicate values.

What proof can you provide that what you are claiming is true?

htrisakti3 · Post by **htrisakti3** » Wed Dec 07, 2005 3:00 am

My job is very simple..

TXT infile --> transform --> txtOutfile

txtOutfile has some derived columns, including:
LineNumber = @INROWNUM

Constraint @INROWNUM<>1 (as this line contains file header info)

So far, This happens 3x since 1/11/05 on my system (normally, this job runs 50-60 in a day)

And it's almost impossible to reproduce this error.

In one instance, txt outfile contains 2 lines with line# = 1191 from input file of 1800 lines.

I can provide job in dsx & input & output file generated, but as I said, it's almost impossible to reproduce.

My other thoughts are maybe environment related, as when these happened, CPU idle is nearing 0%, but that doesn't make sense either..

ArndW · Post by **ArndW** » Wed Dec 07, 2005 3:12 am

In all the time that I've been working with DS I've never seen an error in this part of the code. The system variable is autoincremented for each row and is completely independant of the data being processed. I think both Ray and I are saying that it is very unlikely that the error is happening within the @INROWNUM value and that something else is causing your problem.

Difficult to reproduce problems are the bane of our lives!

Perhaps you could add a stage variable to your transform, "ErrorCheck", setting it to "IF ErrorCheck+1 = @INROWNUM THEN @INROWNUM ELSE -1"
and put an additional link into your transformer stage with the constraint "ErrorCheck = -1". In cases where your problem occurs, it should also contain at least one row. If your output contains a duplicate but this link has no output rows you might be a step closer to diagnosing the problem.

kcbland · Post by **kcbland** » Wed Dec 07, 2005 8:36 am

My 2 cents contribution, in 7+ years with DS this has happened to me only because of design error, never because of DS. Are you overwriting the existing file or appending to the existing file? Any stage variable/row rollup occurring?