Today I ran across a pretty straightforward DAX challenge that is made so much simpler thanks to variables. So I decided to share it. Remember folks use variables for each and every measure (even if you don’t think you need them). It will prepare you for the toughest challenges :).
I have known for a long time that data privacy checks can have an impact on the performance of data refresh in Power BI and Excel, but on a recent performance tuning engagement I had the chance to observe just how much of a difference changing these settings can make
The order of the columns in a table in a Power BI dataset doesn’t matter all that much, especially because the Fields pane in Power BI Desktop ignores the original column order and lists the columns in a table in alphabetical order. However there are a few situations where it is important, for example when you are using the DAX Union() function in a calculated table: as the documentation states, when you use Union() “Columns are combined by position in their respective tables”. You might also find it irritating if the columns you see in the Data or Relationships panes in the main Power BI Desktop window make it hard to browse the data or create relationships.
Recently I’ve been doing some more investigations into how data privacy settings work in Power BI. This is a subject I’ve blogged about in great detail already in a series of posts last year, but this functionality is so complex that there is always more to learn. I don’t have any profound new insights to offer; instead this blog post is a write up of a series of experiments whose results shed light onto how the process of setting data privacy levels works end-to-end.
A common problem I see some people struggle with in Power BI is when a slicer contains a (Blank) record for some reason. The cause of the problem is not obvious and hence it is not clear how to fix it. This article describes what causes this to occur and also how to fix it (properly, and also with a work around if you can’t fix it properly).