Category: Power BI

Shabnam Watson goes investigating:

In this post, I am going to look at automatic partition maintenance by Power BI service for datasets with Incremental Refresh and focus on what happens to the partitions as time goes by. To do this, I am going to set up a couple of sample datasets with different Incremental Refresh (IR) policies with and without the Hybrid option, schedule automatic refreshes from the Power BI Service, and record how their partitions change over time. As a result, this post is going to get updated as time goes on as it documents how the partitions evolve.

Read on to learn more about what Incremental Refresh does and how things have changed over time. This looks like a post to come back to a few times.

Mara Pereira shares a tip:

Probably one of the most annoying things about creating bookmarks is… updating them!

However, there is a trick that will make your life so much easier and the process a lot faster.

And the trick is…

GROUP YOUR VISUALS and always select the option “SELECTED VISUALS” when creating your bookmark

Read on to see how it works.

Reza Rad shares some thoughts with us:

DAX is the language of writing calculations in Power BI. We use DAX to write calculations such as year-over-year change and percentage, or percentage of the total or rank of customers by their yearly revenue. Writing calculations in DAX takes time, and you may likely need to re-use a calculation in multiple reports.

Creating copies of the PBIX file every time for reusing the calculation is not ideal. The better approach is to have a shared dataset created by DAX calculations and then create thin reports with live connections to the shared Power BI dataset. Using a shared dataset ensures that all the reports are using the same DAX calculations. If a change is needed, it is only needed in the shared dataset. Maintaining a solution like this would be much easier.

Click through for a dozen or so recommendations.

Marco Russo and Alberto Ferrari ask who you believe, them or your lying eyes:

When looking at a report, it is natural to double-check the numbers produced. The simplest and most intuitive way is to verify whether the total equals the sum of individual rows. This behavior is extremely natural and mostly effective. Nonetheless, the total is the sum of rows only for additive measures, which are measures that are naturally computed as a sum.

When working with business intelligence solutions, sooner or later a developer will author a calculation that is non-additive. At that point, the total can no longer be computed by summing the rows for a very good reason: it would be inaccurate. When users complain about the fact that the rows do not sum up, seasoned BI developers offer a rational explanation of the reasons why the number are not summed: this process often provides a better understanding of how values are computed. Choosing the easy way out of introducing additivity in a naturally non-additive calculation means losing the opportunity to generate accurate calculations, and relying on inaccurate values.

Read on for examples and how to understand how to deal with non-additive or semi-additive features.

Chris Webb wants to sort out some performance issues on calculation groups:

A few weeks ago I wrote a post showing how you can use the new EvaluateAndLog DAX function to diagnose performance problems relating to the use of the Switch function. Did you know that calculation groups can experience similar performance problems though? In some scenarios limited evaluation takes place for all calculation items, not just the one you expect; luckily you can use EvaluateAndLog to diagnose this too. In this post I’ll show you a simple example.

Read on for the example.

Gilbert Quevauvilliers reads the chain of custody documents:

As often happens blog posts originate from a customer requesting something I have not figured out before.

In this example the requirement was to be able to determine which data sources were being used by which tables, which were then associated to one or many Power BI datsets.

While I was working through this I figured out I could take it one step further and also if required have the actual Power Query as part of the report.

Read on to see what Gilbert came up with.