Register now to learn Fabric in free live sessions led by the best Microsoft experts. From Apr 16 to May 9, in English and Spanish.
I've been asked by the business to come up with a method to provide fast reporting for the past 8 weeks, while leaving all previous weeks available to query knowing those scenarios will take a performance hit.
Here's the current model:
When the user selects a week in the previous 8 weeks from the date table, which is also on the aggregation table, I can tell that it's working correctly in DAX studio with an aggregation hit. However, once a user selects a week that is NOT on the aggregation table, but is on the date table, DAX studio shows that it's still an aggregation hit and the measure returns null.
It shouldn't be possible for it to have found a match on the agg table since this week number doesn't exist on it:
Any help/direction would be greatly appreciated!
Solved! Go to Solution.
Hi @swolfe2 ,
Sorry for that the information you have provided is not making the problem clear to me.
According to this: However, once a user selects a week that is NOT on the aggregation table, but is on the date table, DAX studio shows that it's still an aggregation hit and the measure returns null.
It shouldn't be possible for it to have found a match on the agg table since this week number doesn't exist on it.
Actually I think It's an expected behavior:
Best Regards,
Eyelyn Qin
Yes, that's the same behavior I'm seeing on my side.
I suppose the DAX that's being generated is just looking for "Is there an aggregated column based off of the year?" and not also "Does this year exist on the aggregated table, too?".
Hi @swolfe2 ,
Sorry for that the information you have provided is not making the problem clear to me.
According to this: However, once a user selects a week that is NOT on the aggregation table, but is on the date table, DAX studio shows that it's still an aggregation hit and the measure returns null.
It shouldn't be possible for it to have found a match on the agg table since this week number doesn't exist on it.
Actually I think It's an expected behavior:
Best Regards,
Eyelyn Qin
Yes, that's the same behavior I'm seeing on my side.
I suppose the DAX that's being generated is just looking for "Is there an aggregated column based off of the year?" and not also "Does this year exist on the aggregated table, too?".
Covering the world! 9:00-10:30 AM Sydney, 4:00-5:30 PM CET (Paris/Berlin), 7:00-8:30 PM Mexico City
Check out the April 2024 Power BI update to learn about new features.
User | Count |
---|---|
107 | |
100 | |
85 | |
77 | |
66 |
User | Count |
---|---|
120 | |
111 | |
95 | |
83 | |
75 |