Find everything you need to get certified on Fabric—skills challenges, live sessions, exam prep, role guidance, and more.
Get startedGrow your Fabric skills and prepare for the DP-600 certification exam by completing the latest Microsoft Fabric challenge.
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?".
User | Count |
---|---|
81 | |
79 | |
71 | |
70 | |
54 |
User | Count |
---|---|
107 | |
99 | |
88 | |
79 | |
67 |