Hi all,
I am facing some errors in the stage variable derivation stage.
My source data is like this
code name
---------------
A USA
B Uk
C AUS
----------------------------
I want the out put in the condition that if code=A then name should be AAA.For this I have used the stage variable as below.
inputlink.code stagevar1
if stagevar1="A"
then stagevar2="AAA" stagevar2
else inputlink.name
in the out put link I have taken the values like this
stagevar1 code
stagevar2 name
after runnig the job i am getting the output like this
code name
A 0
B UK
C AUS
can anybody suggest what is the problem here
Putting condition in stage variable
Moderators: chulett, rschirm, roy
for stagevar2 set the derivation to
Code: Select all
if stagevar1="A" then "AAA" else inputlink.name
Regards,
Nick.
Nick.
Re: Putting condition in stage variable
Hi,
It was bad programing tech if you used stage variable for this type of tiny issue. Use direct link. Stage variables are only use when you use derivation of stage variable frequently( at least more than 3 times) in the mail derivation.
Thnaks-
Pranab Das
It was bad programing tech if you used stage variable for this type of tiny issue. Use direct link. Stage variables are only use when you use derivation of stage variable frequently( at least more than 3 times) in the mail derivation.
Thnaks-
Pranab Das
sorry I had misguided u somewhat with the condition in my earlier message .... so here's the modified one....
Directly write the following condition in the derivation for the 'Name' column in the Transformer stage that
"If inputlink.code='A' then 'AAA' Else inputlink.Name"
This will work.........Don'tcomplicate things unnecessarily.......
Directly write the following condition in the derivation for the 'Name' column in the Transformer stage that
"If inputlink.code='A' then 'AAA' Else inputlink.Name"
This will work.........Don'tcomplicate things unnecessarily.......
Code: Select all
if code=A then name should be AAA
if code=B or C then what output you need
Anyway go with Amit_111 approach
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
I use stage variables quite often and for multiple reasons. Primary reason is to keep derivations in one place for multiple use in other places as noted in this thread... sometimes even just for one other place.
However that's hardly the only reason. Another is the ability to simplify and 'self-document' a job. However, that is only possible when you use meaningful names for the stage variables. Something like "stagevar1" would never pass a peer review with me. Our standards say that all stage variable names start with 'sv' and are meaningful for the context they are used in. I also use them as booleans quite a bit to simply constraints and deviations. A simple example...
A stage variable called "svRecordFound" whose derivation is simply "Not(LookupLink.NOTFOUND)" which automagically sets the stage variable's value to true or false. Then a constraint or derivation could say "svRecordFound" or "If svRecordFound Then X Else Y" - doesn't work any different than using the Link Variable directly but sure reads easier.
A slightly more complex example. Several business rules must be enforced and the net evaluated for a constraint. Rather than put an extremely long and messy derivation in the field and see someone else scratch their head and say 'What the...' when they open the job, I'll break it up into logical stage variables named for the individual portion of the rules they are evaluating. If someone needs to see the actual "If X And Y Then Z Else If A or B Then QQQ Else If ..." code, they can check the stage variable. Otherwise, in the constraint they'll see something like:
Poor generic examples, in reality my names would be much more tightly coupled to the job and transforms. Hopefully, you get my point. Do yourself and everyone who comes after you a BIG favor - use meaningful names for everything - stages, links, stage variables - everything. Sure, it's a little bit of a PITA at first but practice and a good set of standards go a long way towards easing the 'burden' of naming objects.
However that's hardly the only reason. Another is the ability to simplify and 'self-document' a job. However, that is only possible when you use meaningful names for the stage variables. Something like "stagevar1" would never pass a peer review with me. Our standards say that all stage variable names start with 'sv' and are meaningful for the context they are used in. I also use them as booleans quite a bit to simply constraints and deviations. A simple example...
A stage variable called "svRecordFound" whose derivation is simply "Not(LookupLink.NOTFOUND)" which automagically sets the stage variable's value to true or false. Then a constraint or derivation could say "svRecordFound" or "If svRecordFound Then X Else Y" - doesn't work any different than using the Link Variable directly but sure reads easier.
A slightly more complex example. Several business rules must be enforced and the net evaluated for a constraint. Rather than put an extremely long and messy derivation in the field and see someone else scratch their head and say 'What the...' when they open the job, I'll break it up into logical stage variables named for the individual portion of the rules they are evaluating. If someone needs to see the actual "If X And Y Then Z Else If A or B Then QQQ Else If ..." code, they can check the stage variable. Otherwise, in the constraint they'll see something like:
Code: Select all
svRule1Passed And svRule2Passed
-craig
"You can never have too many knives" -- Logan Nine Fingers
"You can never have too many knives" -- Logan Nine Fingers