Forum Discussion
GROUPBY Context Transition
RobertSlattery- I may be off-base here but I believe you have a fundamental misunderstanding of how measures function. For measures in DAX, the starting filter context is ALWAYS the context of the visual. So, if you use a measure in a single row, that's the starting context of the measure unless you change it by wrapping the calculation in a CALCULATE or CALCULATETABLE and using something like an ALL, ALLEXCEPT or other type of filter that fundamental and specifically changes the original filter context.
Your first calculation doesn't do any of that. Your first calculation starts with a filter context of a single row. So, that is the starting filter for the GROUPBY, which is not a context/filter changing function. It is just going to do it's thing on whatever data it has access to based upon the starting context/filter.
Therefore, it is really, really difficult to see exactly what is going on with your functions with what I would consider 1/3rd of the critical information. You have presented the calculations, which is good but we are missing the context in which you are placing them (your use of them in visuals, what visuals, what other information is around them, etc.) And the actual data or a sample of data that is being used so that we can replicate the issue/behavior without recreating it all.
Hi Greg_Deckler, Yes I know, but since I have a work-arround, I'll have to post an example later when I get time. Having said that, I would have thought that context transition or not on a particular function - outside of a Calculate - would be a straight-up knowledge thing. (And since MS doesn't bother to document properly, we have to create knowledge by posting questions.)
Most functions do not apply a context transition outside of Calculate or CalculateTable so I find it surprising that GROUPBY does, especially given the rmarks in the documentation here
I don't know where to look in the docs bout if FILTER fails silently on a table dynamically created within a measure but again this is a specific question about a specific scenario that doesn't require data I think.
RobertSlattery- I may be off-base here but I believe you have a fundamental misunderstanding of how measures function. For measures in DAX, the starting filter context is ALWAYS the context of the visual. So, if you use a measure in a single row, that's the starting context of the measure unless you change it by wrapping the calculation in a CALCULATE or CALCULATETABLE and using something like an ALL, ALLEXCEPT or other type of filter that fundamental and specifically changes the original filter context.
Your first calculation doesn't do any of that. Your first calculation starts with a filter context of a single row. So, that is the starting filter for the GROUPBY, which is not a context/filter changing function. It is just going to do it's thing on whatever data it has access to based upon the starting context/filter.
Therefore, it is really, really difficult to see exactly what is going on with your functions with what I would consider 1/3rd of the critical information. You have presented the calculations, which is good but we are missing the context in which you are placing them (your use of them in visuals, what visuals, what other information is around them, etc.) And the actual data or a sample of data that is being used so that we can replicate the issue/behavior without recreating it all.
Youre right Greg_Deckler, the context is there regardless of the Calculate. I'm a bit confused about this, given all the mysterious handwaving about Calculate efecting a ~Context Transition~. SMH.
OK, thanks again.
Correct, the CALCULATE just gives you the option of changing the context/filters of the calculation. So, if you use something like FILTER then you are taking the existing context from the visual that is coming into the calculation and becoming more selective. Alternatively, you can use things like ALL and ALLEXCEPT to remove context and then, potentially add context/filters back to it.
Understanding DAX hinges on understanding the concept of context and paying close attention to the context in which the code is running.
Actualy, apart from all the handwaving about context transition, the reason I had this wron view was because of this answer by v-huizhn-msft , which solved the problem at the time but, I could not understand the explanaition why. Are you able to ttranslate the aswer as to why?
RobertSlattery- Actually yes I believe I can.
Your measure firstDateVisible is using an ALLSELECTED filter, which partially removes original filters but keeps others and I'm not going to try to explain it exactly because it's a weird function. I would reference https://www.sqlbi.com/articles/understanding-allselected/
However, when you put that measure inside of a CALCULATE with a FILTER of ALL, you actually changed the context again. The end effect is that the ALL inside your CALCULATE removed any and all original filters that the ALLSELECTED was preserving.
So, the solution was to use a VAR and essentially grab the value returned from your firstDateVisible measure, preserving the original filter context for ALLSELECTED. Then, once you have that value calculated in the correct context, you can safely use that variable inside of your CALCULATE because it's just a value at that point versus a calculation that is modified by the change in context to ALL.
I hope that makes sense.
"However, when you put that measure inside of a CALCULATE with a FILTER of ALL, you actually changed the context again. The end effect is that the ALL inside your CALCULATE removed any and all original filters that the ALLSELECTED was preserving. "
Greg_Deckler, no way. The measure inside the filter is applied to the ALL(Dates) table, not constrained by it. If it was constrained by the filter it was building then, the whole thing would disappear up it's own arse because that would be a circular reference. The [open orders] measure in the Calculate is affected by the filter but not the [firstDateVisible] one, that would be 'ken crazy. No, I think it's just a bug or an ef'ed if I know moment in the design of the lexicon.