Trouble combining text variables

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?

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

1 Like

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.

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

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

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.

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.

Hit on this again today :slight_smile: Always wrap your expressions with a LINK( ) (Weird function to handle nulls)

Hi @mellerbeck,

thanks for your input.
This is totally clear to me. I have solutions for that.
The issue is, that TULIP is meant to be a no code platform everybody can build apps with.

But most people with no coding experience will struggle to understand this and keep that in mind all the time. The Result from 'Hello '+[null] is no error, it is [null]
This is not intuitive for most new users.

When I allow to set ‘’ as a default (empty) string, and this setting is default for new variables, one will only use null if really needed.

agree 10000% I was just mainly making a mental note (and maybe should be in some tulip errata, that if you add to a null the whole expression becomes null)