chulett wrote:Sorry, but I can't explain the behaviour you saw. I use the ROWNUM variables "all the time" and have never seeing this issue. Have you opened a case with your official support provider? What exact 7.x version do you have and on what UNIX platform? If it's earlier than 7.5.1a then the answer may be an upgrade.
Craig,
My version is 7.5.1.
I'll log the report to my support provider.
Thanks for the info and your time.
As i've noted in my first quetion, Is there any limit in the number value to stage variable?
Let me clearly explain.
If i wanna generate sequence number say, based on the number of records and if i'm using stage variables to generate the same then how much value does stage variable accomodate?is there any limit or no limit?
Mike wrote:Couple of questions:
1) Do you have an active stage connected to another active stage?
2) Do you have row buffering enabled?
I seem to recall having weird issues with row buffering many moons ago in one of the 7x releases. I don't remember if I ever saw it with @INROWNUM (might have), but I definitely remember an issue where the aggregator stage mysteriously did not include one row's value. Turning off row buffering solved the aggregator issue. And as mysterious as the issue was, it was repeatable for that specific set ot test data.
If you haven't already, try disabling row buffering to see if your @INROWNUM issue goes away.
Mike
Mike,
1.No. As i said earlier, I had a sequential file as a source , transformer and the Sybase table connected through ODBC stage.
2.Buffer has been enabled i suppose.
So, is row buffering a root causer for this issue?
You suppose? Earlier when I asked you said "I didn't set any buffer alloaction". Check and be sure. If it is (and I'd really have to question why) run your tests again with it off as suggested.
-craig
"You can never have too many knives" -- Logan Nine Fingers
chulett wrote:You suppose? Earlier when I asked you said "I didn't set any buffer alloaction". Check and be sure. If it is (and I'd really have to question why) run your tests again with it off as sug ...
It's not like that craig. After our conversation only i had checked with my team.Because i forgot the settings what we had previously (as we had changed our logic and ran it successfully).
Will it be the problem of buffering alone or what?
chulett wrote:You suppose? Earlier when I asked you said "I didn't set any buffer alloaction". Check and be sure. If it is (and I'd really have to question why) run your tests again with it off as sug ...
It's not like that craig. After our conversation only i had checked with my team.Because i forgot the settings what we had previously (as we had changed our logic and ran it successfully).
Will it be the problem of buffering alone or what?
When your original design with buffering on gives you a problem and that problem goes away with buffering off, then yes I'd say it was a "problem of buffering". Of course, you'd have to specifically test that and let us know.
-craig
"You can never have too many knives" -- Logan Nine Fingers
chulett wrote:When your original design with buffering on gives you a problem and that problem goes away with buffering off, then yes I'd say it was a "problem of buffering". Of course, you'd have to specifically test that and let us know.
Actually we didn't touch the row buffering (i'm sure craig). We jus had changed our logic using stage variables and ran it.
