Forum Discussion
Context transition issues
- 7 years ago
Anonymous, v-juanli-msft
For those interested, it appears this is actually a bug.
See this other post.
Anonymous
Ok, so you were looking for some additional "fun" with your Column but the fun is not complete without our friend CALCULATE. So I've added a CALCULATE and created a further variant with VALUES instead of ALL:
Col_B yields the same result as your Column, i.e. 10 in all rows. In this case, ALL is just returning a (one-column) table with all rows of 'Product'[ProductKey] and thus the result is the same for each row, regardless of context transition.
Col_C is also interesting. Since we use VALUES and not ALL this time, the table used by FILTER is in this case affected by the filter resulting from context transition. Since inside FILTER we have two nested row contexts for 'Product'[ProductKey], let's agree that we'll refer to the table inside FILTER as TableFil and we'll use 'Product'[ProductKey] to refer to the column of the overall table (which would be EARLIER('Product'[ProductKey]) within FILTER). TableFil is a one-row column with value that of the current row in 'Product'[ProductKey]. FILTER scans TableFil and checks each row (only one thus) against the condition. The return value of FILTER will be a one-row column at rows with 'Product'[ProductKey]<=10 and an empty table for the rest. Thus, with COUNTROWS, the result per row of 'Product'[Col_C] will be a 1 for the former group and a blank for the latter.
Agreed? In this case all seems to add up nicely
Anonymous, v-juanli-msft
For those interested, it appears this is actually a bug.
See this other post.
- Anonymous7 years agoNot applicable
Good catch! Do you get a prize from msft? :smileylol:
- AlB7 years ago
Community Champion
Anonymous
I would support the idea :smileyvery-happy: but it wouldn't be fair. Other people saw it first, as can be read on the other post.:smileyhappy: