Forum Discussion
Understanding Context Transition with Table Filter Arguments
I believe this is Auto-Exist kicking in. SUMMARIZECOLUMNS combines all filters from the same table into one filter, so in your second evaluation, you have DATA, and DATA[Group] - and they get combined since it is the same table.
Take a look at the detailed explanation of SUMMARIZECOLUMNS() here and then the Auto-Exist issue you may need to contend with here.
Auto-exist is a pain to recon with.
I believe this is Auto-Exist kicking in. SUMMARIZECOLUMNS combines all filters from the same table into one filter, so in your second evaluation, you have DATA, and DATA[Group] - and they get combined since it is the same table.
Take a look at the detailed explanation of SUMMARIZECOLUMNS() here and then the Auto-Exist issue you may need to contend with here.
Auto-exist is a pain to recon with.
Thanks. Auto-Exists does seem like the likely explanation, at least for the SUMMARIZECOLUMNS cases since using a dimension table for group resolves the issue.
For the ADDCOLUMNS examples, using a dimension table doesn't seem to help so maybe there's something else happening. Auto-Exists also doesn't explain why RANKX and SUMX behave differently for these.
I'm certianly not an expert in Auto-Exists, but I believe it returns a table with specific info, therefore SUMX and RANKX are operating on a different result set than the SUMMARIZECOLUMNS without the filter table. That is why you are getting different results. SQLBI does a deep dive into Auto Exist in this video.
If you could mark one or more of these as the solution so this thread can be marked solved, we'd appreciate it.Why would SUMX operate on a different result set than RANKX in the ADDCOLUMNS examples (where the results match each other using SUMX but don't match using RANKX)?
My only guess would be that there might be some kind of internal optimization such that SUMX isn't actually behaving as an iterator whereas RANKX still must.
