Forum Discussion
Helper IVDAX coalesce function consumes all available memory
Ok, vgeldbr - see if this helps. I think this is a modeling problem. Your aggregate status was another table in a 1:Many relationship with the Engagement Codes table, and the latter wasn't filtering the former.
I could have worked on some DAX to do some crossfiltering, but that is more complex than it needs to be. The Aggregate status is really just a lookup table it seems, so I just merged it into the Engagement table. You can see my results in the lower right.
This is a super simple measure.
Actuals = VAR varActualCount = COUNTROWS(Actuals) RETURN IF( ISBLANK(varActualCount), 0, SUM(Actuals[ExpenseUSDCurrentFYTD]) )If there are no rows in the Actuals for a given code, return zero, otherwise the total. At this point, your dim_engagement codes doesn't even need to be loaded. Use your Engagement codes as the DIM table and the Actuals as a FACT table - a perfect Star Schema. See my PBIX file here. Look at the merge I did in Power Query.
Microsoft Guidance on Importance of Star Schema
Community ChampionOk, vgeldbr - see if this helps. I think this is a modeling problem. Your aggregate status was another table in a 1:Many relationship with the Engagement Codes table, and the latter wasn't filtering the former.
I could have worked on some DAX to do some crossfiltering, but that is more complex than it needs to be. The Aggregate status is really just a lookup table it seems, so I just merged it into the Engagement table. You can see my results in the lower right.
This is a super simple measure.
Actuals =
VAR varActualCount = COUNTROWS(Actuals)
RETURN
IF(
ISBLANK(varActualCount),
0,
SUM(Actuals[ExpenseUSDCurrentFYTD])
)If there are no rows in the Actuals for a given code, return zero, otherwise the total. At this point, your dim_engagement codes doesn't even need to be loaded. Use your Engagement codes as the DIM table and the Actuals as a FACT table - a perfect Star Schema. See my PBIX file here. Look at the merge I did in Power Query.
Microsoft Guidance on Importance of Star Schema
Helper IVThanks for all of the help. I obviously realized I could just create a calculated column in the Engagement Code table but wanted to avoid the large amount of redundant data that would create. I'm still having all sorts of issues with the data model but your help has moved me forward (along with some of my understanding).
- edhans
Great vgeldbr - yeah, I avoid calculated columns at all costs. This was done with a Power Query merge, but there, or a custom column in Power Query, or your source data, is much better practice. Glad I was able to help.
In general, try to avoid calculated columns. There are times to use them, but it is rare. Getting data out of the source system, creating columns in Power Query, or DAX Measures are usually preferred to calculated columns. See these references:
Calculated Columns vs Measures in DAX
Calculated Columns and Measures in DAX
Storage differences between calculated columns and calculated tables
SQLBI Video on Measures vs Calculated Columns