Trouble combining text variables

Support, Troubleshooting, & Help
1

I am trying to combine 4 text variables into a string to be stored in a table record. This seems simple, can someone find where I went wrong? The variables and the table record are all of the type “Text”. Would it cause a problem if some of the variables are blank?

image
image1472×642 13.5 KB

2

Hey @Ebitner -

You hit on my biggest suspicion. This will fail if any of the variables are null. I would wrap each variable in a link() function to catch these cases so:

Link(Variable.Adjust_status1,"")+
Link(Variable.Adjust_status2,"")+
Link(Variable.Adjust_status3,"")+
Link(Variable.Adjust_status4,"")

The link function will look for the first non-null value in its parameters, so if the variable is null, it will replace that null with an empty string.

Let me know if this doesn’t resolve it.
Pete

3

I have also had an expression fail because of a NULL variable, except mine was Expression = Variable + ‘Some additional text’.

I had hoped the expression would still be valid if the variable was blank and pass the additional text but did not if the variable was NULL.

4

The reason is probably, that NULL is a different datatype than text. And you cant combine two datatypes. As soon, as there is a value (even a blank string) it is a text and you can combine it.

@Pete_Hartnett @Ebitner
This solution works, but keep in mind, that the variable keeps being NULL!
If you have other Triggers handling these variables you always have to keep that in mind.

I often have a kind of preset / reset trigger on step enter, where I set crucial variables to a good starting point (as clear counter or empty strings …).
So I make sure, I dont mix in some expired values from other steps or NULL values.

@Pete_Hartnett
Is there any activity to allow an empty string as default?

1 Like
5

Hey @thorsten.langner -

Technically, this is a quite easy change to make:

  • When a variable is null and being used in an expression, replace it with a logical value of the same type (if its a string, replace it with an empty string)

The concern with this sort of change is not the change itself, but the impact it could have on existing app -

  • If we flipped the switch for all apps, some production apps would have triggers that previously failed, that don’t fail anymore, this could drive incorrect behavior, reeking havoc on operations.
  • if we only flipped the switch on new versions of apps, it wouldn’t impact apps running in production, but could potentially create unexpected changes in subsequent versions of apps that could be hard to identify.
  • if we only turned on this behavior for new apps, we might go years before the old behavior is entirely unused and we can deprecate
  • if we only turn this on for new Tulip accounts, we have the same issue as above, but also it means we need 2 versions of documentation for each of these different behaviors.

Because of these challenges, we tend to avoid changes like this unless absolutely necessary because they mandate a tremendous amount of work (communication to customers, automated checks of apps, etc) to do right.

Hope this helps shed some light on the way we think about these changes.
Pete

6

Hi @Pete_Hartnett,

thanks for your reply.

I totaly aggree with not changing the default. I think I expressed myself misleadingly.

I asked to optionaly set the default value of an variable to an empty sting, in the variable window.

image
image975×324 8.89 KB

I can leave it empty to get NULL as is, or set a default (like “default string” above). I want to actively set it to “empty string” as an optional default value.