Toad World® Forums

Using #_ACTIVITY_RESULT# Will Not Work in If Conditions or Variables if the action was successful

This is a bit hard to explain, but I’m trying to use the #_ACTIVITY_RESULT# variable, which holds information on the previous tasks that are run. Essentially, I’m wanting to use this variable to show if there is an error or not in the previous task. It’s not a problem to record the #_ACTIVITY_RESULT# in a set variable or if condition when THERE IS an error, because it populates information into this. The problem is when there IS NOT an error because it brings back and empty string. And this becomes a problem for setting variables or using this #_ACTIVITY_RESULT# in an if condition because neither allow an empty value and errors out when running saying “Expression can’t be empty”

So basically, what I’m wondering, is if there is a way around this to make this come back with some type of value when there is NOT an issue, so I can continue to evaluate and use this in my if actions or build set variables based on this? If not, this may be an enhancement request question, but instead of bringing back and empty string, is there a way for it to bring back something like “Success” or something, so we can use this #_ACTIVITY_RESULT# to evaluate if actions error or not correctly?

Hope this makes sense. Thanks as always.


I have never used the #_ACTIVITY_RESULT# variable. In what version is that application variable available?

Maybe set that variable (or your own if system variable can’t be set) to ‘Success’ at the beginning of each task and then set at end to the end result of task?

I agree it would be best if a non-null value indicated success.

I believe its been available in versions from at least 3.7 or 3.8. I currently use 4.1 though and its definitely there.



It’s not a variable that I set, its a variable TDP sets based on the success or failure of each action. Even if I was able to set the variable of #_Activity_Result# to success before the task, it will still change to a no value after the action is ran and successful, which again creates issues for if actions because it has to have a value represented for the if/then procedure or else it fails saying there’s nothing there on the variable.


If the variable has no value only on success, can you test for isnull or isblank or not exists? Of course I don’t see any of those functions in Toad automation. You can try Length(#_Activity_Result#) = 0 for success and see if that works. Good luck.

Thanks chad.king for your post - i agree this is not how it should work in a perfect world.

I just browsed the Toad World’s Idea Pond and found topics from other users with some new ideas of built in variables:

I believe your idea is related in the same manner. So for your specific issue i have created QAT-10230 task for our team to improve this in a more user-friendly and intuitive way. But for the improvement of the system variables in general i’ve created QAT-7323 last year so hope it will get prioritized this year (=

Greg, I’ve absolutely tried that. I even tried length = 0. The problem is, is that it wont even try to evaluate the variable if there’s nothing there. It errors first chance it gets that there’s nothing in it. I guess TDP has something with any variable not having any info and returning this error. I’d love to see if there was another way to bypass, but no luck so far.


As a temporary workaround you can set the “Stop on error” to false (checkbox on the Activity info tab) so when the IF activity fails it will not interrupt script workflow and you can rely on any previous value that you’ve set.

That’s the thing. I’m trying to create a “retry” type of feature, so I actually do have to have the stop on error unchecked so it can continue if there is an error. The problem is purely the success. I have to be able to evaluate the success to proceed at all with any type of if or looping activity. A good example is the log command. if I just log the #_Activity_Result# after the fact, it will actually show “nothing” or the error depending on the error of the previous action. That’s absolutely exactly what I need other actions to do. Therefore, say you try an if action and say to evaluate the #_Activity_Result# and if there is any type of error that comes back, do something. Even doing this and not even specifying on the “else” part anything, it will work ONLY if there is an error. If there is success, it cannot evaluate this variable on success to even look for the failure message and errors out immediately. I need it essentially not to error and allow the if action or the looping action to evaluate even if there is no error or nothing that came back in #Activity_Result#. Unchecking the stop on error at this point would just send it on past the if action and go to something else and I need it actually to decide which way to go on the if action. I know its hard to explain but I really just need to actually have it not error on the evaluation of the variable in the if/looping actions similar to how it does in the log action.


Thanks Martin. I wish there was a way that I could “trick” the system at this point to allow me to use that #_Activity_Result# variable without error until something could be done with it. If ya’ll see anything or have any other ideas I’m open completely to trying them. thanks!


Martin added QAT-10230 to see what we can do on this issue. It is scheduled to be looked at for TDP 4.3. We have already closed out TDP 4.2

Hey guys,

i have changed the logic so any automation activity which succeeds in execution will have the ‘Succeeded’ string literal word in the _ACTIVITY_RESULT variable. This way you should be able to create a simple if activity with the ‘#_ACTIVITY_RESULT#’ != ‘Succeeded’ expression and it should do the magic.

Also please note that in case you forgot the name of this variable you can find it after you add the “Set variable value” activity to the workflow it will then be available in the variable name dropdown list.

Could you guys please confirm whether this is suitable enough for your needs?


That sounds like it would work wonderfully. Thanks so much Martin!