Find a nasty Bug in Qlik Sense. Don't trust Qlik Engine 100%, especially when using Variables in conbinations with line breaks! See video-attachment.
If Qlik Supports is interessted and needs more details, please contact me. It is not possible to publish the App here.
I'm not so sure that there is really a bug - of course your result changed but this doesn't mandatory mean that's a bug.
By using variables you need in general to be cautious that the variable contained the right content. If variables have parameter or multiple ones are combined and/or even nested you need to be especially carefully that all parts of them are expanded properly - particularly if they also contain any kind of comments. There were already multiple postings here in the community complaining that the combination of variables didn't work but by a closer look on all the expanded parts it was shown that they influenced/excluded each other in a rather not so obvious way.
Beside this your used approach of: var1 + var2 worked often but has potential to fail if any of the operands didn't return a valid numeric results respectively isn't interpreted as it. Therefore it's usually better to ensure it by a explicitly converting/formatting of the results and also using brackets to wrap them, like: (var1 + var2) or often even more suitable with: rangesum(var1, var2).
Thanks for your message. To differentiate your postings with my finding: all what you have mentioned has nothing to do with my case. It returns numbers which can be used for further calculations. There is no syntax-error, no wrong format. With both results you can make further calculations and can be shown in objects. Never saw in other programming languages that a linebreak will change the value of the result.
So what does this mean for us qlik-developers?
1) not use linebreaks anymore?
2) not use variables anymore?
3) if this is not a bug and it is as designed, so how looks the design? "to be careful" by using variable is not clear and will upset us qlik-developers.
Nevertheless there may be a bug and your observed differences might be caused through that the parser and/or the engine treats both versions of your expression differently.
But unless it's checked that the variables are defined and called properly I wouldn't name it a bug. Therefore I couldn't agree with your statements. Here just two quite common cases which will end in errors respectively in unexpected results and which are not at least bugs:
Assuming a variable: var with the content of: sum(value) which returned a floating number. If now the used default-formatting for numbers has the comma as delimiter, like this result here: 1,5
If you now call: $(var) as a single statement in an expression everything will work. But if there are further statements like:
1,5 + 1
it will fail because it's an invalid syntax because the comma is now interpreted as a parameter-delimiter - a correct definition would be:
1.5 + 1
and in this case you need an additionally converting/formatting.
The second example: Assuming the following variables:
sum(value1) // some comment
Now the call of:
S(var1) + $(var2)
is expanded to:
sum(value1) // some comment + sum(value2)
which means there is no result of sum(value2) to be added to sum(value1) because it's so a part of the comment. By changing the call to:
the expansion looked like:
sum(value1) // some comment
and it will of course add both sums and return a different result.
Therefore my hint that there are quite natural explanation possible and that the variables needs to be defined/called carefully and if they return unexpected results they need to be expanded to ensure that they are used properly.
Thank you for your posting.
I went through my code, and I can confirm that your explanation with the command line makes the difference!
sum(value1) // any comment has an impact with and without the commend line
But I have to say, I am really disappointed to make this experience. That means, not to use any command lines anymore. This is really a bad behaviour of qlik engine, and for my understanding still unlogical and impractical.
I guess I am not the only one who is working with variables and command lines. Many other users did used wrong results without knowing it!
My urgent recommendation to the Qlik-Developer Team:
1) Change this behaviour, so command lines will have no affect to any result
2) If Qlik don't want or can not change it, at least it should appear a warning message! E.g. when typing "//" or somewhere else
Thank you for your understanding.
I can ensure you that my (virtual) list of possible improvements in regard to the variable-handling in Qlik is quite long but again I can not completely agree with you.
If users have "wrong results without knowing it" it means they neglect an important part within the development of applications and within their usage. IMO all results of an object/application has to be evaluated if it returned the correct respectively the expected values - and this has nothing to do with or without the usage of variables else there are various other errors possible, from the syntax of the expressions to logically issues with the datamodel or the business case and to the quality of the raw-data.
Therefore the development should start with a few table-boxes and table-charts to check the data-quality, the relation of the data against eachother and to get aggregated results on the various dimensions. If everything is ok. they might be consolidated within KPI's. With a reversed approach it's very difficult to get to the right results.
Beside this you could avoid your issue by using the following way to define your comments:
sum(value1) /* any comment */
I can imagine you have a long improvements list. As always you have to thing which point is more important then the other one. For me, this one should be very high in the list. Why?
1) If you want to comment your variables and want to use them in other parts, you have to use linebreaks in your formulas. So like this:
( $(var1) -$(var2) ) / $(var3)
2) not using any commentary. It doesn't matter if using "//" or /* any comment */. (Markus: This will answer your question, that /* any comment */ did also not help.