It's always good to be reminded of cleaning up the code. Did this change just optimize readability or does it also optimize performance?
@HavensConsulting8 ай бұрын
The clients fact table was only 50k rows so there wasn't enough data to actually get a MS change. But using DAX studio there were definitely fewer calls being ran since I was using fewer CALCUALTES and calling the same measure repeatedly was reduced. So a combo of both optimization and readability here.
@scramiro17 ай бұрын
A good video (that I can´t see much on youtube) would be how you debug when a formula is not providing the number you seek. Some option:, use TOCSV to see the outupt table, dax query of the visual to see filter context, etc. How do you do this?
@HavensConsulting7 ай бұрын
I have an upcoming video to show examples of the DAX query view. Otherwise the video with Daniel Otykier where he walks through the DAX Debugger in Tabular Editor 3 is also fantastic :) kzfaq.info/get/bejne/o5qXbKWpyLvKZIk.html
@DanielWeikert8 ай бұрын
Did you see Performance improvement?
@HavensConsulting8 ай бұрын
The clients fact table was only 50k rows so there wasn't enough data to actually get a MS change. But using DAX studio there were definitely fewer calls being ran since I was using fewer CALCUALTE's and calling the same measure repeatedly was reduced. So a combo of both optimization and readability here.
@Nalaka-Wanniarachchi8 ай бұрын
Nice case study,But it's always better to remember that variables are getting fixated before return statement.
@HavensConsulting8 ай бұрын
Good reminder, in the example I ran all the calculations are being ran before the return statement. So now calculation issues with this. Generally it's when you need to apply additional filters on a VAR that you need to consider where to apply the filter (during/after) declaring a VAR