Forum Discussion
Suspected BUG when using ALL with multiple non-ignored slicer values
You can post your Issue here
Include the link to your sample file. They may also respond to this posting...
But if you look at the response marked as solution here
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.
That tells you everything! This is by design.
Unfortunately I don't think they'll do anything about it at this point. :smileysad:
EDIT: Confirmed by Marco Russo below - this is by design!
UPDATE: 9/24/2018
https://www.sqlbi.com/articles/understanding-dax-auto-exist/
“The golden rule of data modeling is always the same: always use star schemas.
If a column has to be used to slice and dice, then it needs to belong to a dimension.
Numbers to aggregate, on the other hand, are stored in fact tables.
Tabular lets a developer deviate from the regular star schema architecture.
This does not mean that doing it is always a good idea. It seldom is.”
Alberto Ferrari
Community ChampionMarco Russo said he will write about this and here it is! :smileyhappy:
https://www.sqlbi.com/articles/understanding-dax-auto-exist/
“The golden rule of data modeling is always the same: always use star schemas. If a column has to be used to slice and dice, then it needs to belong to a dimension. Numbers to aggregate, on the other hand, are stored in fact tables. Tabular lets a developer deviate from the regular star schema architecture. This does not mean that doing it is always a good idea. It seldom is.”
Thanks marcorusso ! :smileyhappy:
UPDATE:
Thanks AlbertoFerrari ! :smileyhappy:
Just noticed the above article was actually written by you.
Sean, thank you for linking to this great article by AlbertoFerrari!