Unlock a world of possibilities! Login now and discover the exclusive benefits awaiting you.
Hi,
I am trying to filter values to a range btw two numbers, which is working when I use only one decimal but not two
I have the follwoing table:
fact:
LOAD * INLINE [
Id, Uplift, Price
1, 0.5 , 15
2, 2, 12
3, 4.2, 18
4, 1 , 11
5, 0.9, 11
];
And want a set analysis like: Avg( {< Uplift={">=1.1<=3"} >} Price )
When I change the 2nd restriction to a decimal it won't work anymore. It works with one decimal, no matter the place, but not with two. A few examples:
Avg( {< Uplift={">=1.1<=3"} >} Price ) WORKS
Avg( {< Uplift={">=1.1<=3.1"} >} Price ) DOESN'T WORK
Avg( {< Uplift={"<=3>=1.3"} >} Price ) WORKS
Avg( {< Uplift={"<=3.1>=1.1"} >} Price ) DOESN'T WORK
Any help is appreciated.
Cheers
Kuni
Using a really old QV release (11.2) I see the same behaviour. I assume an parsing-error of the set analysis because the following worked:
Avg( {< Uplift = {">=1.1<=$(=31/10)"} >} Price )
and maybe it's an alternatively for your case.
- Marcus
Using an older version of QV (12.20) available here, your expressions work just fine.
Which exact software version are you using?
Really Sorry. Mixed up the forum.
Using Qlik Sense 12.16 and not QlikView
Using a really old QV release (11.2) I see the same behaviour. I assume an parsing-error of the set analysis because the following worked:
Avg( {< Uplift = {">=1.1<=$(=31/10)"} >} Price )
and maybe it's an alternatively for your case.
- Marcus
Yes it worked. Seems indeed to be a parsing error.
Thanks!
Another way to bypass it could be use a different number-notation like:
Avg({< Uplift={">=11e-1<=31e-1"} >} Price)
which avoids the use of . as the delimiter.
Stefan mentioned yesterday it worked for him with the normal number-notation like expected and it's the first time I see this as issue and even if I think that this kind of number-comparing isn't often used I doubt that's really a unique use-case.
Therefore I could imagine that this behaviour is caused from the number-formatting variables and/or the OS region-settings which might replace the point with a comma and the following calculation-steps fail on it because they interpret the comma as parameter-delimiter. Nevertheless it's a parsing-error ...
- Marcus