Why in the following measure the slicer on the "ATA" field is ignored and 2018 dates appear even they are not selected in the slicer? (see imagen below. "|" is just my list separator ",")
The table is not affected by any other slicer.
Yes, that's the main recommendation they give in literature, but that approach only works when you have few dates in the model. In my case, almost all my data are dates, tables full of dates, so creating a date table per date column or dozens of inactive relationships makes the model confusing, the DAX complex and the visualization task time consuming. I really find useful the auto hierarchies Power BI creates automatically in each date.
If you know how to handle these scenarios where dates are the main data type on the model and still use a date table, would be very helpful if you could share with me the links or sources to learn about it.
Hi @Greg_Deckler thank you for your reply, but why is the measure evaluated in 2018 dates? shouldn't the slicer filter the rows in the table too and consider only 2019 months?
For example, in this new measure, 2018 still is used to evaluate the measure even I'm not repleasing the "ATA" date column in the filter argument of CALCULATETABLE, why?
Hi everyone! specialiy @Greg_Deckler
I found the explanation to what is happening and has to do with the behavior of the custom visual.
The behavior is not wrog, is just unexpected.
The custom visual "Timeline 2.1.1" (the one I'm using to filter the table) picks the date field and not the autohierarchy as built-in slicers do.
Take a look at the two imagens below which explain easily what is happening.
The Power BI slicer automatically picks the autohierarchy and the custom visual does not:
Because the table visual is using the autohierarchy as row headers, the custom visual filter doesn't affects the table visual, only the measure.
Thank you @Greg_Deckler for your file that guided me to make tests with the custom visual.
Because your slicer is using the column ATA and your CALCULATETABLE's filter clause ALSO uses the column ATA. Thus, the filter in the CALCULATETABLE's filter clause REPLACES the context filter on the slicer. This is just how CALCULATETABLE works. It is clearly spelled out in the documentation:
The CALCULATETABLE function changes the context in which the data is filtered, and evaluates the expression in the new context that you specify. For each column used in a filter argument, any existing filters on that column are removed, and the filter used in the filter argument is applied instead.
This is what I explained before. I am not sure how to explain this any other way.
Calm down @Greg_Deckler I'm just asking and learning.
The issue with the measure and the CALCULATETABLE behavior is understood, my question now is, why the measure is being evaluated on 2018 dates? Whatever the measure is, it shouldn't be evaluated on 2018 dates (rows of the table visual) because the slicer should be hiding those rows on the visual, no?
Or the slicers don’t affect row and column headers and just affect measures inside the tables?
@juan_pablo - I can't recreate it so it is difficult to know what is going wrong on your end. See attached PBIX file.
Check out the November 2023 Power BI update to learn about new features.
Read the latest Fabric Community announcements, including updates on Power BI, Synapse, Data Factory and Data Activator.
130+ sessions, 130+ speakers, Product managers, MVPs, and experts. All about Power BI and Fabric. Attend online or watch the recordings.