Putting condition in stage variable

[sjordery]

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

[nick.bond]

for stagevar2 set the derivation to

Code: Select all

if stagevar1="A" then "AAA" else inputlink.name 

[Amit_111]

Why use a StageVariable?
Directly write the following condition in the derivation for the code column in the Transformer stage that
"If inputlink.code='A' then 'AAA' Else inputlink.code"
This will work...... why complicate things unnecessarily.......

[pranabdas]

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

[Amit_111]

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.......

[rafik2k]

Code: Select all

if code=A then name should be AAA

Basically what you want to do with this?

if code=B or C then what output you need

Anyway go with Amit_111 approach

[ray.wurlod]

This is a misleading comment from you. Why 2 months? Where did you pull that number from?

[chulett]

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:

Code: Select all

svRule1Passed And svRule2Passed

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.