Skip to main content
Announcements
Have questions about Qlik Connect? Join us live on April 10th, at 11 AM ET: SIGN UP NOW
cancel
Showing results for 
Search instead for 
Did you mean: 
george55
Partner - Creator III
Partner - Creator III

Bug: Attention with Variables and command lines!

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.

Labels (1)
6 Replies
marcus_sommer

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).

- Marcus

george55
Partner - Creator III
Partner - Creator III
Author

Hi Marcus,

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.

George

 

marcus_sommer

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:

var1:
sum(value1) // some comment

var2:
sum(value2)

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:

S(var1)
+ $(var2)

the expansion looked like:

sum(value1) // some comment
+ sum(value2)

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.

- Marcus

george55
Partner - Creator III
Partner - Creator III
Author

Hi Marcus

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.

Georger

marcus_sommer

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 */

- Marcus

george55
Partner - Creator III
Partner - Creator III
Author

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. Commentation
    1. Everybody who has to learn something new, don't want spend to much time in it. So a system should be as good as possible self-explaining. That's also the Qlik-Strategy, to provide a tool which can be use for many users, even for not very IT-affine people (e.g. Self-BI) . That's maybe be the reason why Qlik decided to implemnt Qlik Sense, which has less burden, uses KI, thinks like a datamanager... to take many manual jobs from a user, even systems and datamodel gets more complex. I believe that commenting is something very important and should have a high value. Everybody who has to look someones else code, know what I mean.
  2. Habit
    1. Every newbie in a new programming languages (doesn't matter which one) will instinctively try to use common constructs like: For, next, loop, if, loads, variables and commentation. Believe Qlik also thought to provide a programming language which is similar to the common standard, to make the life much more easier for newbies. A newbie have to find out what is the appropriate syntax of thy system to use. E.g. some languagues uses for  commentary "'", others "#" and Qlik is using "//" and "/*". Once he finds out, he is thinking the behiour should be the same as in other languages. Commentary is not a processing engine-code and will be ignored. Here Qlik uses an exceptions comparing with other languages.
  3. Instruction
    1. A developer do have to consult guidance to use the syntax correct. In this particular case for commenting he will find the instructions here: https://help.qlik.com/en-US/qlikview/April2019/Subsystems/Client/Content/QV_QlikView/LoadData/commen... . There is written:     "All text on a line that follows to the right of//(two forward slashes) will be considered a comment and will not be executed" .     There is nowhere described that a comment will affect a result (it doesn't matter with, without variable, with or without line breaks etc.). So how should a developer know that there are special processes he has to consider when commenting?
  4. Evaluation
    1. Fully agree with you that a developer should evaluate it the returned values is correct. I also fully agree with you that you should start with a few table-boxes to check data-quality. Maybe you have noticed that in my video there were plenty of table-boxes, exactly for that reason. This was also the reason why I did find this issue, because I had differences and did know why. Have to say, that I spend so much time to find the issue, have done many variations. Never thought that a line break and a comment line is the perpetrator. Find it out by accident, started to put line breaks to read the code better.
  5. Large numbers
    1. When you start small and everything looks good you will reach once a point to outsource some part of your code. So you will start implementing variables. And you have to test every variable itself. Here also, everything looked good. Then you are realise that your project become complicated, so you start commenting. The numbers are getting bigger and you don't have the possibility to check the data anymore. But you think it is ok, because the setup worked fine with small numbers. Or do you check everytime if the pi-function did give you the right number?

 

Suboptimal solutions:

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.