From the help:

Translate to constant when running

Optional. If you, for example, use a Date Variable in the "Variable value" text box it will be converted to a string when the Variable runs the first time. For example, if you use the current date as a Variable it will always show the current date when running the Task. If this is checked, it will show the current date once and then display the same date in each execution.



I find the exact opposite to be true.

Hi doconnor,

The text explaining the checkbox is true.

Whatever you have in the variable text box will be changed to the value of the variable if it is changed to a constant. So the value of the variable contains the result of the variable. After this change there can't be a variable in the variable.

So every {....} is parsed to it's value.

Optional. If you, for example, use a Date Variable in the "Variable value" text box it will be converted to a string when the Variable runs the first time.

True, the {...} part is parsed to a real string and stored back into the variable. So the content of the variable is changed.

For example, if you use the current date as a Variable it will always show the current date when running the Task. If this is checked, it will show the current date once and then display the same date in each execution.

All the above can happen just once, the variable doesn't contain any {...} parts anymore.


Hope I made it clear how it works.

Regards,
Erik

---

Hi Erik

I'm not sure I understand this either then, although I have probably misunderstood your explanation.

If I set 'Translate to Constant when running' each time I run the job the variable updates to the variable value I define and doesn't remove it (see attached), in fact the only difference I can see when I select this is that I can see the value it is changed to in the tasks description field instead of the 'Only available to Runtime' message. i.e. The variable value isn't changed permanently from '{TRIGGER(Active|LastTrigger|File.Result.FullPath)}' to the constant 'C:\@@Trigger\RUBIS\TYPE4Q123.csv.

In the attached screenshot different filenames are processed and these are reflected in the variable value.

Or..... did I misunderstand your explanation?

Cheers

Andy

Hmm, ok lets talk about this a little further:

I have a variable called TestVar.
I use the SET variable task and I set the value to {DATENOWADD(Years|1|yyyyMMdd)}, without the checkbox checked, this is the result:

Variable 'TestVar' was updated to: {DATENOWADD(Years|1|yyyyMMdd)}

If I check the box 'translate to constant' the output will be:

Variable 'TestVar' was updated to: 20140826

So using the checkbox the value you set is parsed and the result is stored in the variable, otherwise the 'variable value' is stored (without parsing) in the variable.


😕 The misleading part here is when you retrieve the value both show: 20140826.
If you go into the variable window you can see the actual value stored in the variable. There you can see the difference.

If I retrieve the value next year, one will be 2015MMdd, depending on the date I retrieve it and the other still 20140826. This is becouse one is still using the dynamic datenowadd part, the other has 20140826 in there.

Original feature request 


Regards,
Erik

---

Hi Erik

Thanks for the explanation. So if my understanding is correct, I guess for my purposes it doesn't matter if the variable is set to 'Translate to Constant' as a task within a job as the variable value will still be updated each time the job runs specifically for that job, i.e. using your example of {DATENOWADD(Years|1|yyyyMMdd)} it will always be updated when it runs. Mostly, it is better for me to see the actual value the variable was set to in the Tasks description, rather than what it is being set to (e.g. '20140205' rather than {DATENOWADD(Years|1|yyyyMMdd)}.

Where it would be usefull I guess is if hardcoded variables have to be set (and fixed), for example, setting a fixed Server Name, or perhaps an Environment (such as TEST or DEV) so that the variable doesn't have to be redefined elsewhere?

Cheers

Andy