Forum Discussion
ALL() function ignored / inconsistent functionality when also using report level filter
While working on an analysis report we came across (what seems to be) an issue in Power BI, and are not sure if this is a bug or a misunderstanding on our part. In summary, a measure we have created which uses the ALL() filter modifier seems to calculate incorrectly when a report level filter is applied, and the correctness of the ALL function seems to vary depending on what is selected in the page filter.
We have been able to reproduce the strange behaviour using some very simple test data. The test data set we are using to portray this issue is shown in the image below:
When we implement the measure shown in the image below,
and have all the selection boxes of the DateID report filter selected,
the ALL() function works as expected, and ignores the corresponding slicers that we try to apply to the CountALLInstances measure that we have. See images below.
Without start day or sick days filter applied (correct results)
Note that the CountFilteredInstances is similar but does not have the ALL function, and always performs as we expect.
With a start day filter applied (correct results)
With a sick day filter applied (correct results)
However, when we only have SOME of the DateID report filter options selected, the ALL() function is no longer able to turn off the corresponding slicers that we apply to the CountALLInstances. The value for CountALLInstances that we would expect to see regardless of whether the Start Day or Sick Day slicer is applied is “6”, but this is not the case as can be seen in the images below
Without start day or sick days filter applied (correct results)
With a Start Day filter applied – incorrect results despite the ALL function. CountALLInstances should still be “6”.
With a Sick Days filter applied – incorrect results despite the ALL function. CountALLInstances should still be “6”.
We would greatly appreciate if anyone is able to identify whether this is a bug or is expected behaviour, and thus how we would work around this.
The desktop file is linked below for reference.
Hi,
I got a response from Microsoft to my ticket and wanted to share the result. This did fix the problem as per screenshot below. I'm not sure why there is a difference between PBI and PowerPivot results, but I'm grateful to have something to work with. It is not clear whether the Power BI support team considers this a bug or not as they refer more to "problem" and "workaround". I was under the impression everything could be done from a flat table in PBI if only one source being used, but it's not much admin to add to link up at least. Thanks all for the input.
Microsoft support response
Use the ALL function on the dimension attribute instead of the column in the fact table, and use the slicer on the dimension attribute, this seems to workaround the problem.
22 Replies
Hi all,
Can anyone tell me if this does seem to be a bug or if we are doing something wrong? Would greatly appreciate if anyone can respond and say whether they also find this strange behaviour?
Cheers
Thanks so much, I really appreciate having someone else confirming this. I'll do as you recommend!
Am waiting on Microsoft Power BI team to respond... For interest - I built the same test in PowerPivot and found that it worked perfectly. Screenshot below
Which is a little concerning for Power BI. It was pretty obvious to me that something didn't seem right, but what if there are other DAX engine issues which seem more subtle? I'm sure Microsoft will help sort it out quickly though.
Thanks for pointing out this issue and raising with Microsoft!
I played around with your example and created a simple example of my own, and the behaviour seems to be the same whether the filters are applied through slicers or Report Level filters.
The behaviour seems to be:
- For the set of columns that have 'slicers' (or I guess any filter) applied (i.e. the Columns for which ISFILTERED( Column ) = TRUE ), cross-filtering is applied among those columns.
- This results in a reduced list of values per filtered column.
- When the DAX expression is evaluated, ALL(...) correctly clears the filters on columns specified, but the cross-filtered values for the other columns are retained!!!
For example, when you filtered Date ID = 01, 02, 03 and StartDay = Mon, cross-filtering reduced Date ID down to just 01.
Then the DAX expression cleared the filter on StartDay, but Date ID was left filtered to just 01, resulting in a row count of 3.
Of course this is all incorrect behaviour. Hopefully fixed soon!
Yep! Curious to see what they say about this?
Hi,
I got a response from Microsoft to my ticket and wanted to share the result. This did fix the problem as per screenshot below. I'm not sure why there is a difference between PBI and PowerPivot results, but I'm grateful to have something to work with. It is not clear whether the Power BI support team considers this a bug or not as they refer more to "problem" and "workaround". I was under the impression everything could be done from a flat table in PBI if only one source being used, but it's not much admin to add to link up at least. Thanks all for the input.
Microsoft support response
Use the ALL function on the dimension attribute instead of the column in the fact table, and use the slicer on the dimension attribute, this seems to workaround the problem.
Thanks for the update bswylie
I don't think this is an adequate solution - I will send some feedback myself :)
There could be man valid scenarios where you want to clear a filter on one column and retain filters on another column from the same table (e.g. two columns in the same lookup table).
This issue seems to be in a similar vein to this one (but a different problem):
https://www.sqlbi.com/daxpuzzle/unexpected-filter-behavior-in-calculate/solution/
I have seen that the problem is generated by the DAX code below generated by Power BI.
The issue is the behavior of SUMMARIZECOLUMNS, but I have to say that I never thought to use SUMMARIZECOLUMNS using two columns from the same table in two table filter arguments. If this is what Power BI does, then SUMMARIZECOLUMNS should work accordingly.
The reason why Excel works is because Excel generates queries in MDX using a completely different approach.
However, I woulds say that this is definitely an issue in the DAX engine.
DEFINE
VAR __DS0FilterTable =
FILTER(
KEEPFILTERS(VALUES('Sheet1'[Date ID])),
OR(OR('Sheet1'[Date ID] = "01", 'Sheet1'[Date ID] = "02"), 'Sheet1'[Date ID] = "03")
)
VAR __DS0FilterTable2 =
FILTER(KEEPFILTERS(VALUES('Sheet1'[Start Day])), 'Sheet1'[Start Day] = "Tue")
EVALUATE
SUMMARIZECOLUMNS(
__DS0FilterTable,
__DS0FilterTable2,
"CountALLInstances", IGNORE('Sheet1'[CountALLInstances])
)
Did Microsoft ever solve the bug? I am currently experiencing a similar problem, however I do not understand the solution provided in this post.
You need to use a star Schema.
So that the attribute you use in the All () function will function well.
For example - if you wish to see ALL Product sales, no matter what you choose in the slicer, you need to use a product table connected to the fact (sales) table.
Then use the All() function on a column in the Product table. this should work well.
I found out that the ALL() function is ignored when it is applied to a column that is "sorted by" another column ... When I remove the "Sort By Column", it's working again...
Hi folks,
I am running into the same issue. Is there a solution to resolve this wihtout breaking out all columns that I potentially ever want to filter by into separate dimension tables? I mean there has to be a way to at least ditch all the filter context in a measure and then just reapply only the slicer that I want to keep, right?
Background:
I have a table with some 300 columns in my data model that users want to build reports for and there is absolutely zero chance I am breaking this out into dimension tables. IMHO is no proper version control or automation / programmation feature built into MS so I just won't do it. For the exat same reason, there are other voices that consider star schema not fit for many modern ways of working as explained in Why star schema is set up for failure and in Should auto exist and sort by column implementation be changed?
Cheers, aabtra
