Unlock a world of possibilities! Login now and discover the exclusive benefits awaiting you.
Hi, I have a question concerning the way Outer SetAnalysis modifiers are working.
In my below example, I use an application that contains data for Years 2022 and 2023. There is no data for 2021.
I have a standard calculation that counts the number of Customers that is:
count(distinct Customer_ID) = 1500
If I use SetAnalysis on the field Year only, it will work as expected, using an inner Set Analysis or an outer Set Analysis:
If I do the same but put 2021 instead of 2022, since I don't have data for 2021, the expected result should be 0, which is the case, for both Inner and Outer Set Analysis.
However, as soon as I introduce another set modifier in my inner set analysis, and I put year 2021 in my Outer Set Analysis, the behaviour gets weird:
It seems like, when there is an inner set analysis, and we apply an outer set analysis with a modifier that is not in the data set (Year = 2021 in this example), this outer set analysis modifier is simply ignored, instead of resulting in 0.
After doing some more tests, if we have 2 modifiers in Outer SA (1 out of dataset, 1 within data set), and 1 or more modifiers in Inner SA, the modifiers from Outer SA that is out of dataset will be ignored (like above), but the second modifier will still be considered.
Is this the expected behaviour for Outer set analysis? Should it be the exact same result as when we use same modifier in Inner Set analysis?
I confirm that I don't use and Set Identifier ($, 1, ...)
Thank you in advance for your help
Hi there,
This is something i have seen myself when using the Set Expressions outside of your set analysis. I believe i have feed this back.
I found the issue is caused when your expression is is applied value that doesn't exist in the data. So in your example i assume 2021 doesn't existing in the year dimension. If you added it to the calendar you would find that it would work as expect.
I assume it's working like intended - but may end in unexpected results. The cause is probably that a scenario like yours would need an extra processing to evaluate the states against each other which isn't implemented quite probably for performance reasons.
Another example for a similar behaviour is to add a none existing field in the set analysis, like:
sum({< NoneExistsField = {'whatever'}>} value)
which returned the total results for the value like sum(value) would do because there is simple no evaluation if a field exists or not - the selection couldn't be set and therefore the state is unchanged.
I think in your case it's very similar respectively it caused a kind of conflict which isn't resolved and in such cases:
" ... Inner set expressions have precedence over outer set expressions ..."
Hi both, thank you for the answers.
Related to the Precedence of Inner over outer set expressions, this is the case for the set identifier (1, $, ...) but in my case I don't use any set identifier nor alternate states. This meaning it should end up merging both set analysis, and result in being the same as when I use Year={2021} in the Inner set analysis.
I don't see why this would represent any extra processing than we we apply a 'valid' selection via the Outer set analysis.
I had understood the referenced statement as two different cases:
" ... Inner set expressions have precedence over outer set expressions and if the inner set expression has a set identifier, it replaces the context ..."
and I could imagine that it requires an extra processing. Simplified I think we could the following regard as a one-step processing:
{< F1 = {a,b,c}, F2 = {1}>}
while something like this:
{< F1 = {a,b,c}> * < F2 = {1}>}
requires a second step to evaluate both states against each other and the inner and outer set analysis may behave in a similar way in some scenarios respectively the differences between the inner and outer set analysis may result an impact as if an identifier has been placed.
Hi @vasilev ,
I haven't performed additional tests since then. In the meantime, we performed an upgrade of our Qlik environment, but haven't had the chance to see if it did fix the issue. I'll let you know in the event I find something different in the future!
Br
Hervé