Forum Discussion
Dax query returns unexpected result
- 5 years ago
Hi Usagi_Nakamura ,
Answering to your last question:
Not that I am sure this is Auto-Exist anymore but in the example above, where you exchanged Product[UnitPrice] by Sales[UnitPrice] you were still having all the ingredients to trigger it according to this:
https://docs.microsoft.com/en-us/dax/all-function-dax
"An example where auto-exist and ALL() provide unexpected results is when filtering on two or more columns of the same table (like when using slicers), and there is a measure on that same table that uses ALL()."In your last example ProductSubcategoryKey (ALL), ClassName and BrandName (SLICERS) are still from the same table. Now, while moving ClassName and BrandName to a different table could sort out the issue, we still want to learn why this is happening.
I leave it to the experts, but hoping this is of any help, I reproduced the scenario in PBI with the simplest table possible (just two rows, only one brand/class and no duplicates) to rule out possible causes:
The measure that breaks:
SUMX = VAR CurrentKey = SELECTEDVALUE('Table'[Key]) RETURN SUMX( FILTER( ALL('Table'[Key]); 'Table'[Key]<CurrentKey ); [Sum of UnitPrice] )A measure that works:
With Calculate = VAR CurrentKey = SELECTEDVALUE('Table'[Key]) RETURN CALCULATE( [Sum of UnitPrice]; 'Table'[Key]<CurrentKey )In PBI:
- A Table visualization with only one of the columns used to slice shown:
- Ok to slice by the one not present in the visualization:
- But as soon you slice by both of them the measure with SUMX breaks:
Regards,
Hi Payeras_BI ,
Thank you for giving me a hint which must be helpful.
I will try to understand the concept of dax-auto-exist and to apply it to this matter.
Kindest regards,
Hi again Usagi_Nakamura ,
To be honest I also struggle to understand why the 51.663,53 for every row, let me know if you find out.
But, at least, if you follow the advice at the end of the article you get rid of the issue:
"In simpler data models with only one table and with a fancy data distribution of values, it might be possible to run into auto-exist problems. When this happens, the easiest solution is to avoid using a single table and to build a proper star schema instead."
Exact same query but now slicing on columns belonging to the dimension tables:
Regards,