How I like to present this information

I think the information when the data model was last updated is probably the most important. I like to place this information directly on the report so that it is immediately visible and, in case the report is printed, it is also included on the print (…yes, many customers want to be able to print their reports 😐 ). Since this information is only needed in the second place and takes up more space in case of a data model with several fact tables, I provide this information via a visual header tooltip. This tooltip can be called up when this information is needed and thus does not constantly take up space on the report. Here I provide three pieces of information:

1. The name of the table +
2. the date column, on the basis of which I determine the max date and
3. the actual maximum date

The animated GIF below shows how I provide this information:

If you are now wondering how this information gets into the report, read on.

Latest data model refresh

There are several approaches to store and report the lastest update of the data model. I present 3 versions and all those versions are based on a Power Query query, which provides the interesting timestamp , which is then loaded into the data model as a disconnected and invisible single-column, single-row  table.

Version #1: DateTime.LocalNow()

You can find several solutions for this topic which use the M-function DateTime.LocalNow() to load a table which stores the current time at every refresh of the data model. I blogged about it in 2017 (in German) and here you can find a similar version from Kasper de Jonge. The problem with this approach is the following: The datetime value returned by DateTime.LocalNow() depends on the system of the computer on which the M script is executed. Which computer this is is sometimes not clear at first sight. Here are a few scenarios as an example:

You publish manually from Power BI Desktop to the Power BI service

DateTime.LocalNow() returns the datetime value of the operating system on which Power BI Desktop runs.

Scheduled refresh based on cloud data sources (no Gateway involved)

In case you are working with cloud data sources, the M-script is executed on the server in the Microsoft data center, where your Power BI datasets are located. In my case this is a data center in Ireland. Ireland is not in the same time zone as Germany. Therefore DateTime.LocalNow() returns a different value here than e.g. on my local laptop.

Scheduled refresh based on on-premises data sources (Gateway involved)

If you automate the data update to the Power BI service through an on-premises data gateway, all M-scripts are executed in the gateway before they pass through the network in compressed form to the Power BI service. Thus, the datetime value returned in this case depends on the system on which the gateway is installed.

There are certainly other scenarios. What these 3 points should show is that DateTime.LocalNow() is probably not the safest method to get the desired result. Let’s look at alternatives.

Version #2: DateTimeZone.FixedUtcNow() to the rescue

An alternative approach would be to use the function DateTimeZone.FixedUtcNow() in combination with DateTimeZone.SwitchZone() like so: DateTimeZone.SwitchZone( DateTimeZone.FixedUtcNow(), 1). While DateTimeZone.FixedUtcNow() displays the current time in ‚Coordinated Universal Time‘, the second parameter of the DateTimeZone.SwitchZone() function lets me shift the UTC time by x hours (and also minutes if needed). This sounds like a great alternative to DateTime.LocalNow() but the devil is in the details.

Since I live in Germany and we are still jumping diligently between summer time (aka Daylight savings time) and winter time here, in my case this difference to UTC time cannot be static, but has to move between 1 and 2 depending on the date. I have already blogged about this here in German.

So this approach leads definetely to a useful result, but instead of calculating the – sometimes changing – difference to UTC time, it would be nicer if you could simply specify the desired time zone and get the datetime value, wouldn’t it? In this case I use REST API calls.

Version #3: Calling a REST API

Instead of worrying about how to calculate the difference between UTC and my own time zone, you could use a web service of your choice. The following script calls a REST API that returns the current date and time in the desired time zone (passed as parameter), which in my case is CET – Central European Time.

Whichever of the above methods you choose to save the time of the lastest data update: The result will be a single-column and single-row disconnected table in the data model, which you will probably hide there.

Putting this info on the report

To put this info into a report, you should put the datetime value into a DAX-measure, so that you can control the formatting (including line breaks). The following DAX statement does the job:

LastRefresh =
„Latest model refresh: „ & UNICHAR ( 10 )
    & FORMAT ( VALUES ( ‚LatestRefresh'[timestamp] ), „dd/mm/yyyy hh:mm:ss“ )

UNICHAR(10) creates the line break and the FORMAT() function makes sure I can format the datetime value as I need it. Put this measure in a card visual and you’re good to go. Now I make sure that the transaction data in the fact tables is up to date.

Last record of the transaction tables (aka fact table)

In case the data sources doesn’t already provide the data in the necessary structure, I am a strong advocate of doing all ETL tasks in Power Query, even if DAX could partially do the same tasks. Therefore, there are almost never columns or tables calculated with DAX in my data models. In the current case, this is different. My data model has 3 fact tables. In order to know if my data sources contain current data, I select the corresponding date columns from the fact tables, which I want to check for actuality. Normally these are date columns which are related to the calendar table. Doing this in Power Query could take muuuuch longer than doing it with DAX, so the decision is easy.

To create a table using DAX, which gives me the necessary information, I use the following DAX statement:

MaxDatesFactTables =
{
     ( „PnL_ACT (column: ‚Investment date‘ )“, CALCULATE ( MAX ( PnL_ACT[Invest date] ), ALL ( PnL_ACT ) ), 3 ),
     ( „PnL_PLAN (column: ‚date‘)“, CALCULATE ( MAX ( PnL_PLAN[date] ), ALL ( PnL_PLAN ) ), 2 ),
     ( „PnL_Forecast (column: ‚date‘)“, CALCULATE ( MAX ( PnL_FC[date] ), ALL ( PnL_FC ) ), 1 )
}

The result looks as follows:

The three columns contain the following information:

• Value1: Name of the fact table + info, based on which column the actuality of the data was determined.
• Value2: The maximum date of this specific column
• Value3: Using this value I can sort the table in the report.

Now let’s take a look at how I prefer to present this info.

This is how I prefer to present this information

I think the info, when the dataset had it’s latest refresh is important almost everytime… that’s why I include it on every page… but what about the latest dates in each fact table? This can be important, but I hardly need this info every single time I take a look at a report page… This is where visual specific tool tips become handy… I create a tooltip page (see the official documentation to know how that works) on which I display the disconnected table „MaxDatesFactTables “ as a matrix. Since the table created in DAX has the headings value1, value2 and value3, I overwrite them in the column captions of the matrix visual: value1 becomes Table and value2 becomes Max Date.

To place this tooltip in the visual header of the card visual, I go to the format properties of the card visual in which the LatestRefresh is located.

I turn on the visual header (if not already done) and activate the ‚Visual header tooltip icon‘. After that a new menu item appears in the format properties: ‚Visual header tooltip‘. Here I select my tooltip page in the field ‚report page‘. Done! 🙂

Additional information in the Power BI service: When was last uploaded?

In addition to the lastest refresh of the data model and the actuality of the data in the data source, the question sometimes arises as to when the data was last uploaded to the Power BI service. If you update your data via scheduled refresh, the time of the last model refresh and upload to the Power BI service will be (nearly) identical. However, if you manually publish your data to the Power BI service (via Power BI Desktop), then model refresh and publishing to the Power BI service are two processes that can vary greatly in time. This information is available to every user directly in the report.

And as mentioned at the beginning: Even if you automatically update your Power BI dataset (and thus the lastest model refresh and the upload to the Power BI service have identical times): If you want to print the report, you have to put the info on the report yourself 😉

Cheers from Germany,

Lars

Lars Schreiber

Lars ist Berater, Entwickler und Trainer für Microsoft Power BI. Er ist zertifizierter Power BI-Experte und Microsoft Trainer. Für sein Engagement in der internationalen Community wurde Lars seit 2017 jährlich durch Microsoft der MVP-Award verliehen. Lies hier mehr…

ssbi-blog.de

Der Beitrag Let your users know how up-to-date their data is erschien zuerst auf THE SELF-SERVICE-BI BLOG.

The goal

The goal is to create a row at the end of the table that represents the total for the month columns and contains the row label ‚Total‘ in the first column.

Alternative Solutions

Imke and Bill have sent me their solutions, but the comments of the source code are from my pen. With this I wanted to make it easier for you as a reader and I hope that I didn’t make any mistakes. If you find any mistakes here, it’s on me.

Solution #1 – by Bill Szysz

Solution #2 – by Bill Szysz

Solution #3 – by Imke Feldmann

Conclusion

There are many roads to the solution. These 3 here, seem very creative to me and show quite different ways to solve the problem. With the available (relatively small) amount of data, the 3 methods seem to be almost equally fast. Of course this would have to be tested with larger amounts of data, but that’s not what this post is about :-). I thank Imke and Bill a lot for their solutions. I have learned a lot. Which of them do you find the most exciting?

Cheers from Hamburg, Germany

Lars

Lars Schreiber

Lars ist Berater, Entwickler und Trainer für Microsoft Power BI. Er ist zertifizierter Power BI-Experte und Microsoft Trainer. Für sein Engagement in der internationalen Community wurde Lars seit 2017 jährlich durch Microsoft der MVP-Award verliehen. Lies hier mehr…

ssbi-blog.de

Der Beitrag 3 ways for sums over columns in Power Query erschien zuerst auf THE SELF-SERVICE-BI BLOG.

Achja, bei diesem Beitrag handelt es sich um meinen 100. Blogbeitrag. Echt Wahsinn, wie viel da über die Zeit zusammenkommt 😛

Als Abonnent meines Newsletters erhältst Du die Beispieldateien zu den Beiträgen dazu. Hier geht’s zum Abonnement des Newsletters!

Die Zielstellung

Das Ziel ist eine Datenbasis, die Du Dir exemplarisch wie die blaue Tabelle im Screenshot vorstellen kannst, in das Format der grünen Tabelle zu überführen und dabei die Summen aus Punkt (2) zu erzeugen.

Wenn Dich interessiert, wie Du eine zeilenbasierte Summe über eine dynamische Anzahl von Spalten erzeugst (1), dann kannst Du Dir in meinem Video zur Einführung in lists, records und tables in M, ab Zeitpunkt 42:02 ansehen, wie ich diese Problemstellung löse. Dies ist aber nicht Gegenstand des vorliegenden Beitrags.

Wie Du eine spaltenbasierte Summe über eine dynamische Anzahl von Spalten erzeugst (2), zeige ich Dir im aktuellen Beitrag. Das Ziel ist also eine Summe über alle Kostenstellen in Power Query zu berechnen, dabei jedoch zu berücksichtigen, dass sich die Anzahl an Spalten (in diesem Fall die Monate) verändern können.

Wann sind kalkulierte Summen sinnvoll?

Mit dieser Aufgabenstellung hat mich vor kurzem ein Kollege konfrontiert, der mit der Lösung ausschließlich in Excel, ohne die Verwendung von Pivottabellen arbeitet. In diesem Rahmen ist das Berechnen der Summen okay. Sofern ich eine solche Abfrage jedoch in einer Pivot auswerten möchte (oder im Falle von Power BI Desktop in einer beliebigen Visualisierung), übernimmt diese die Ermittlung von Zeilen- und Spaltensummen und eine in Power Query vorkalkulierte Summe, würde hier zu einem falschen Ergebnis führen.

Lösung

Ich unterteile die Gesamtlösung in thematische Kategorien und hoffe, dass die Lösung damit verständlicher wird.

Drei Listen als Vorbereitung

Zu Beginn der Lösung ist es sinnvoll, eine Liste zu erzeugen, die die Monatsspalten der Quelltabelle beinhaltet. Hierfür erstelle ich insgesamt drei Listen, wobei die ersten beiden dafür da sind, die dritte zu erzeugen.

Liste #1: Alle Spaltenbezeichnungen der Quelltabelle auslesen

Über die Funktion Table.ColumnNames() lasse ich mir sämtliche Spaltenbezeichnungen der Quelltabelle in Listen-Form zurückgeben.

Liste #2: Liste aller existierenden Kalendermonate

Aus der Quelltabelle sollen nur diejenigen Spalten berücksichtigt werden, die einen Kalendermonat abbilden. Daher erstelle ich hier (händisch in M) eine Liste aller existierenden Kalendermonate, um in der dritten Liste gegen diese abzugleichen.

Liste #3: Ermittlung aller Monatsspalten in der Quelltabelle

Über die Schnittmenge der eben erstellten beiden Listen ermittle ich die Monatsspalten in der Quelltabelle. Auf diese Weise kann ich sichergehen, dass meine Lösung auch dann weiterhin funktioniert, wenn in der Quelltabelle weitere Spalten hinzukommen, von denen ich zum jetzigen Zeitpunkt noch nichts weiß. Die Funktion List.Intersect() ermittelt hierbei diejenigen Elemente, die in beiden zuvor ermittelten Listen vorhanden sind. Dies können nur Spalten sein, die den Namen eines Monats tragen.

Somit konnte ich in einer dynamischen Liste die Namen der für die spätere Summenbildung relevanten Spalten speichern, um sie später weiter zu verwenden.

Warum nicht einfach Gruppieren?

Was ich bei der vorliegenden Problemstellung immer im Hinterkopf behalten muss, ist die Tatsache, dass sich die Anzahl der Monatsspalten verändern werden. Auf den ersten Blick liegt als Lösung wahrscheinlich nahe – wie im folgenden Screenshot gezeigt – eine Gruppierung über die Kostenstellen zu erzeugen und die Monatsspalten zu summieren…:

Die Problematik dieser Lösung bei sich ändernden Spalten ist, dass ich das im obigen Screenshot abgebildete M-Statement dynamisch aufbauen muss, d. h. es muss die sich ändernde Anzahl von Monatsspalten automatisch berücksichtigen. Dies ist durchaus machbar, aber nicht trivial. Hierauf gehe ich am Ende dieses Beitrags unter Anmerkungen noch einmal ein.

Mein Lösungsvorschlag für den vorliegenden Beitrag funktioniert weitgehend über die Nutzeroberfläche und nutzt die Funktionalität des Transponierens.

Der Trick: Die transponierte Tabelle

Transponieren meint in diesem Falle das Vertauschen von Zeilen und Spalten einer Tabelle. Dies ist eine Technik, die es selbst im „normalen“ Excel (also ohne Power Query) bereits seit Jahrzehnten gibt. Wie das Transponieren funktioniert und wofür es überhaupt gut ist, zeige ich Dir jetzt.

Vorbereitung auf das Transponieren

Zunächst bereite ich meine Tabelle auf das Transponieren vor, indem ich dafür sorge, dass meine Spaltenüberschriften als erste Zeile verwendet werden:

Nachdem sich die Spaltenbezeichnungen nun in der ersten Zeile der Tabelle befinden, kann ich die Tabelle transponieren, oder „vertauschen“, wie es die Schaltfläche in Power Query beschreibt:

Durch diese Transformation befinden sich die Spaltenbeschriftungen nun in den Zeilen der ersten Spalte und die Kostenstellen (A, B, C…) befinden sich in der ersten Zeile. Dieses Vertauschen von Zeilen und Spalten ist deswegen sinnvoll, weil ich nun die Summe eines Monats – so wie ich es in Power Query in 99% der Fälle tue – durch eine berechnete Spalte kalkulieren kann, die automatisch über alle vorhandenen Zeilen (also die sich ändernde Anzahl von Monaten) rechnet.

Eingrenzen auf zu summierende Spalten

Aufsummieren möchte ich hierbei alle Spalten, die nicht Column1 heißen, denn dort stehen nur Textwerte. Dies geschieht in zwei Schritten:

In Schritt 1 nutze ich erneut Table.ColumnName() um eine Auflistung aller Spaltenbezeichnungen zu erhalten. In Schritt 2 nehme ich die erste Spalte Column1 aus dieser Liste aus, weil dies die einzige Spalte ist, über die ich keine Summe bilden möchte.

Bevor ich jedoch die Summe bilde, muss ich noch dafür sorgen, dass auch nur Datensätze übrig bleiben, in denen in Spalte Column1 auch ein Monat steht. Ich filtere hier jedoch nicht einfach „Kostenstelle“ heraus, sondern gleiche mit meiner Liste der zuvor ermittelten Monatsspalten ab. Dies macht meine Lösung wieder robust gegen Änderungen in der Tabellenstruktur. Diese Technik habe ich in einem anderen Beitrag beschrieben und zeige daher hier nur kurz, wie ich dynamisch nach den Monaten filtere:

Dynamische Summenbildung

Nun kann ich über eine berechnete Spalte alle Spalten außer Spalte Column1 summieren:

Wie bereits zu Beginn dieses Beitrags beschrieben, handelt es sich hierbei um eine Technik, die ich in meinem Video zur Einführung in lists, records und tables in M, ab Zeitpunkt 42:02 erläutere.

Zwischenergebnis

Ich reduziere die Tabelle auf die zwei relevanten Spalten Column1 (in der sich die Monatsnamen befinden) und Spalte Monatssummen in welcher ich gerade die Summen über die Monate kalkuliert habe:

Wichtig ist hierbei, dass ich die Spalten Column1 und Monatssummen selektiert (unter Verwendung der Strg-Taste + Mausklicks) und dann  „Andere Spalten entfernen“ gewählt habe. Damit bleibt diese Lösung auch bei sich ändernder Zahl von Kostenstellen flexibel.

Erneutes Transponieren in die ursprüngliche Struktur

Jetzt transponiere ich erneut und sorge so dafür, dass die Monate – die sich gegenwärtig in Zeilen befinden – wieder in Spalten dargestellt werden… Dies ist notwendig, damit ich das nun kalkulierte Gesamtergebnis je Monat am Ende unter der Quelltabelle anfügen kann, um die Gesamtsummen unter den Einzelwerten darzustellen. Das ganze geschieht in zwei Schritten:

• Schritt 1: Das erneute Transponieren befördert die Monate erneut in die Spalten
• Schritt 2: Die Monatsnamen werden zur Spaltenbeschriftung und in Zeile 1 befindet sich das kalkulierte Ergebnis je Monat.

Das finale Ergebnis: Tabellen zusammenfügen

Das Endergebnis ist beinahe erreicht. Bevor ich an die Quelltabelle die Tabelle anfüge, die die Summen beinhaltet, muss ich der Summen-Tabelle zunächst eine Spalte Kostenstellen mit dem Wert Summe hinzufügen. Dies ist notwendig, damit in meiner finalen Tabelle für die Summen auch in der ersten Spalte „Summe“ als Zeilenbeschriftung ausgewiesen wird.

Wenn Du dazu mehr wissen willst, habe ich hier eine Serie geschrieben, die sich im Detail mit Anfügeprozessen in Power Query beschäftigt.

Fast fertig. Nur die richtigen Datentypen für die Spalten fehlen noch. Den Datentyp für die Kostenstelle vergebe ich fix, aber die Datentypendeklaration für die Monatsspalten muss ich dynamisieren, denn meine Grundannahme für dieses Beispiel ist ja, dass die Anzahl von Monaten variieren kann. Diese Dynamisierung muss ich manuell im M-Code vornehmen:

Diese dynamische Bestimmung der Datentypen ist eine sehr charmante Sache, weil sie meine Lösung robust macht. Leider muss ich dies selbst in M schreiben und kann es mir nicht einfach zusammenklicken. Die Art und Weise dies zu tun, habe ich mir bei Imke abgeschaut und ich kann ihren Beitrag Dynamic & bulk type transformation in Power Query, Power BI and M dazu nur empfehlen. Damit ist meine Lösung vollständig 🙂

Anmerkungen

Meine Lösung soll Dich zum Nachdenken anregen und die Operation Transponieren mehr in Dein Bewußtsein rücken. Dennoch sei an dieser Stelle gesagt, dass dies natürlich sehr schnell sehr inperformant werden kann. Power Query operiert nicht sonderlich schnell über breite Tabellen. Hätte mein Beispiel also 1.000 Kostenstellen, wäre Transponieren keine gute Idee, weil meine transponierte Tabelle dann mehr als 1.000 Spalten hätte. In einem solchen Fall müßte ich mich an die bereits weiter oben beschriebene Lösung machen, die Gruppierungsfunktion zu dynamisieren. Diese ist jedoch nur mit reinem M-Code erzielbar ist… und dies ist eine andere Geschichte und die soll ein andermal erzählt werden 😉

Bis zum nächsten Mal und denk dran: Sharing is caring. Wenn Dir der Beitrag gefallen hat, dann teile ihn gerne. Falls Du Anmerkungen hast, schreibe gerne einen Kommentar, oder schicke mir eine Mail an lars@ssbi-blog.de

Viele Grüße aus Hamburg,

Lars

Lars Schreiber

Lars ist Berater, Entwickler und Trainer für Microsoft Power BI. Er ist zertifizierter Power BI-Experte und Microsoft Trainer. Für sein Engagement in der internationalen Community wurde Lars seit 2017 jährlich durch Microsoft der MVP-Award verliehen. Lies hier mehr…

ssbi-blog.de

Der Beitrag Spaltensummen bei flexibler Tabellenstruktur erschien zuerst auf THE SELF-SERVICE-BI BLOG.

Links

Hier kannst Du Melissas Diagramm (und andere coole Helferlein) herunterladen.

Power BI Desktop-Installation:

• < Windows 10
• >= Windows 10 und bei Vorhandensein eines Microsoft-Kontos

Power BI Desktop Dokumentation

Power BI Desktop updates + alte Installationsdateien für frühere Power BI Desktop-Versionen

Power BI Desktop Samples auf GitHub

Hier kannst Du den Power BI-Berichtsserver und die dafür spezialisierte Version von Power BI Desktop herunterladen

Transkipt

Folgt bald…

Lars Schreiber

Lars ist Berater, Entwickler und Trainer für Microsoft Power BI. Er ist zertifizierter Power BI-Experte und Microsoft Trainer. Für sein Engagement in der internationalen Community wurde Lars seit 2017 jährlich durch Microsoft der MVP-Award verliehen. Lies hier mehr…

ssbi-blog.de

Der Beitrag Podcast – Was ist Power BI Desktop? erschien zuerst auf THE SELF-SERVICE-BI BLOG.

Links

LinkedIn-Profil Ula Jessen

LinkedIn-Profil Lucas Schroth

process.science GmbH & Co. KG

Process Mining Showcases

Transkipt

Folgt…

Lars Schreiber

Lars ist Berater, Entwickler und Trainer für Microsoft Power BI. Er ist zertifizierter Power BI-Experte und Microsoft Trainer. Für sein Engagement in der internationalen Community wurde Lars seit 2017 jährlich durch Microsoft der MVP-Award verliehen. Lies hier mehr…

ssbi-blog.de

Der Beitrag Ula Jessen und Lucas Schroth über Process Mining mit Power BI (German) erschien zuerst auf THE SELF-SERVICE-BI BLOG.

Links

Hier kannst Du Melissas Diagramm (und andere coole Helferlein) herunterladen.

Ich werde häufiger nach Büchern zum Thema Power BI gefragt. Das einzige (gute) Buch, das ich kenne, das die Power BI-Plattform als Ganzes betrachtet, ist das jährlich neu erscheinende Buch „Applied Power BI“ von Teo Lachev. Ich kaufe es jedes Jahr und bin von dessen Qualität wirklich überzeugt.

Transkipt

Folgt bald…

Lars Schreiber

Lars ist Berater, Entwickler und Trainer für Microsoft Power BI. Er ist zertifizierter Power BI-Experte und Microsoft Trainer. Für sein Engagement in der internationalen Community wurde Lars seit 2017 jährlich durch Microsoft der MVP-Award verliehen. Lies hier mehr…

ssbi-blog.de

Der Beitrag Podcast – Überblick über die Power BI-Plattform erschien zuerst auf THE SELF-SERVICE-BI BLOG.

Als Abonnent meines Newsletters erhältst Du die Beispieldateien zu den Beiträgen dazu. Hier geht’s zum Abonnement des Newsletters!

Die Datenquelle

Um die Feiertage je Bundesland zu ermitteln, bediene ich mich der Dienste der Website https://www.arbeitstage.org/. Neben Feiertagen liefert diese Website auch Arbeitstage und Ferientage je Bundesland. Die Feiertage werden seit dem Jahr 2000 dokumentiert. Ein sehr nützlicher Dienst, den ich prima mit Power Query automatisiert auslesen kann.

Die Funktion

Um die Web-Abfrage nicht jedes Mal von Hand erstellen zu müssen, habe ich eine Funktion geschrieben, der lediglich das gewünschte Kalenderjahr als Parameter übergeben werden muss. Das Ergebnis ist dann eine Tabelle mit allen deutschen Bundesländern und den dazugehörigen Feiertagen. Ich bin mir sehr wohl bewußt darüber, dass es innerhalb Deutschlands Feiertage gibt, die sich nicht nur je Bundesland unterscheiden, sondern auch innerhalb eines Bundeslandes je Region verschieden sein können. Dem wird hier nicht Rechnung getragen.

Falls Du wissen möchtest, wie Du meine M-Funktionen in Deinen Projekten wiederverwenden kannst, schau bitte hier nach. Sofern Du diese Lösung für Qlik benötigst, findest Du eine entsprechende Lösung bei meinem Kollegen Mathias Schreiber (nein, wir sind nicht verwandt :-))

Bis zum nächsten Mal und denk dran: Sharing is caring. Wenn Dir der Beitrag gefallen hat, dann teile ihn gerne. Falls Du Anmerkungen hast, schreibe gerne einen Kommentar, oder schicke mir eine Mail an lars@ssbi-blog.de

Viele Grüße aus Hamburg,

Lars

Lars Schreiber

Lars ist Berater, Entwickler und Trainer für Microsoft Power BI. Er ist zertifizierter Power BI-Experte und Microsoft Trainer. Für sein Engagement in der internationalen Community wurde Lars seit 2017 jährlich durch Microsoft der MVP-Award verliehen. Lies hier mehr…

ssbi-blog.de

Der Beitrag Automatisch alle deutschen Feiertage je Bundesland ermitteln erschien zuerst auf THE SELF-SERVICE-BI BLOG.

Als Abonnent meines Newsletters erhältst Du die Beispieldateien zu den Beiträgen dazu. Hier geht’s zum Abonnement des Newsletters!

Teaser – Um diese Funktionalität geht es

Du kennst es wahrscheinlich aus Excel, dass wenn in einer bestehenden Tabelle Filter in mehreren Spalten gleichzeitig gesetzt wurden, Du diese über das Trichtersymbol mit dem roten Kreuz alle auf einmal auflösen kannst. Der folgenden Animation kannst Du eine ähnliche Funktionalität für Power BI entnehmen. In diesem Fall geht es jedoch nicht um die Filter auf einer Tabelle, sondern um die gesetzten Filter auf der Berichtsseite:

Die Lösungsidee

Es gibt in Power BI Desktop keine Funktionalität, die Dich auf einmal alle bestehenden Filter entfernen ließe. Aber es gibt Lesezeichen (engl. Bookmarks), die Dich die aktuelle Konfiguration der Berichtsseite speichern lassen. Wenn Du also manuell alle Filter auf der aktuellen Berichtsseite entfernst und diesen Zustand dann in einem Lesezeichen speicherst, bist Du anschließend in der Lage mit diesem Lesezeichen diesen gespeicherten Zustand immer wieder aufzurufen. Dies gehe ich jetzt mit Dir durch.

Die Lösungsumsetzung

Da ich mit einem Lesezeichen die aktuelle Berichtsseite speichern möchte, wenn gerade keine Filter gesetzt sind, muss ich zunächst sicherstellen, dass auf meine Visualisierungen keine Filter wirken. Dies kann ich wie folgt prüfen.

Wie Du herausbekommst, ob sich Filter auf visuelle Elemente auf Deinem Report auswirken

Um herauszufinden, ob ein visuelles Element Deiner aktuellen Berichtsseite gefiltert wird, fahre mit der Maus über das Trichtersymbol im Header der jeweiligen Visualisierung. Es öffnet sich ein Pop-up-Fenster, dass Dir zeigt, welche Filter auf diese Visualisierung wirken:

Was Du daraus jedoch nicht ableiten kannst ist, woher diese Filter kommen. Hier gibt es natürlich mehrere Optionen:

• aus Datenschnitten/ Slicern (ACHTUNG: Diese können auch ausgeblendet sein),
• aus dem (relativ) neuen Filter-Pane,
• aus Cross-Filtern anderer Visualisierungen,
• etc.

Alle bestehenden Filter manuell auflösen

Damit Du auf Deiner Berichtsseite einen Zustand speichern kannst, in welchem keine Filter wirken, musst Du solange alle potentiell als Filter wirkenden Elemente Deiner Berichtsseite durchgehen und bestehende Filter auflösen, bis keine der Visualisierungen mehr gefiltert wird.

Das Lesezeichen erzeugen

Über Ansicht (1) → Lesezeichen (2) gelangst Du in den Lesezeichenbereich. Hier kannst Du über Hinzufügen (3) ein neues Lesezeichen erzeugen, welches Du über die drei Punkte rechts neben dem Lesezeichen konfigurieren kannst. Nimm die Konfiguration vor, wie in meinem Schritt 4:

Über die gewählten Optionen „Daten“ und „Alle Visualisierungen“ speicherst Du im Lesezeichen den aktuellen Datenstand – nämlich, dass keine Filter gesetzt sind – für alle Visualisierungen. Wenn Du prüfen möchtest, ob Dein Lesezeichen so funktioniert, wie Du es Dir vorstellst, dann setze beliebige Filter in Deinem Bericht und klicke danach mit der Maus auf Dein erzeugtes Lesezeichen (in meinem Fall Lesezeichen „UnFiltered“). Wenn sich daraufhin alle Filter lösen, weißt Du, dass Dein Lesezeichen wie gewünscht funktioniert. Nachdem Du nun ein funktionierendes Lesezeichen hast, geht es darum, es dem Nutzer leichter zu machen, dieses zu verwenden.

Das Trichter-Icon mit dem Lesezeichen verknüpfen

In Power BI gibt es die Möglichkeit Bilder in eine Berichtsseite einzufügen. Ich habe mir das Bild des durchgestrichenen Trichters aus Excel herauskopiert und meiner Berichtsseite hinzugefügt. Das kopierte Bild dient natürlich nur zu Demo-Zwecken. Für ein Kundenprojekt wäre die Auflösung zu schlecht und ich müßte anderweitig nach einem adäquaten Icon suchen.

Ich möchte nun das Bild mit dem Lesezeichen koppeln, so dass ein Klick auf das Bild alle Filter auflöst. Dies geschieht in 5 Schritten:

1. Schritt 1: Selektiere das eingefügte Bild, um dessen Eigenschaften
2. Schritt 2: Unter den Formatierungsoptionen des Bildes Aktionen einschalten
3. Schritt 3: Hier den Typ Lesezeichen auswählen
4. Schritt 4: Das erstellte Lesezeichen UnFiltered wählen
5. Schritt 5: Bei Bedarf eine Quickinfo hinzufügen, die dem Nutzer einen Hilfetext zur Verfügung stellt, wenn er mit der Maus über das Icon fährt.

Auf diese Weise haben wir das erklärte Ziel erreicht, alle Filter auf der Berichtsseite aufzulösen. Wenn Du dies auch für andere Berichtsseiten benötigst, musst Du diesen Prozess für jede Seite wiederholen.

Bis zum nächsten Mal und denk dran: Sharing is caring. Wenn Dir der Beitrag gefallen hat, dann teile ihn gerne. Falls Du Anmerkungen hast, schreibe gerne einen Kommentar, oder schicke mir eine Mail an lars@ssbi-blog.de

Viele Grüße aus Hamburg,

Lars

Lars Schreiber

Lars ist Berater, Entwickler und Trainer für Microsoft Power BI. Er ist zertifizierter Power BI-Experte und Microsoft Trainer. Für sein Engagement in der internationalen Community wurde Lars seit 2017 jährlich durch Microsoft der MVP-Award verliehen. Lies hier mehr…

ssbi-blog.de

Der Beitrag Alle Filter einer Power BI-Berichtsseite mit einem einzigen Klick zurücksetzen erschien zuerst auf THE SELF-SERVICE-BI BLOG.

Als Abonnent meines Newsletters erhältst Du die Beispieldateien zu den Beiträgen dazu. Hier geht’s zum Abonnement des Newsletters!

Anmerkung

Der nachfolgende Beitrag war ursprünglich deutlich länger und detaillierter. Manchmal – Gott sei Dank in diesem Fall zum ersten Mal – kommt es jedoch vor, dass sich ein Leser bei mir meldet und mir mitteilt, dass ich inhaltlichen Unsinn geschrieben habe. In diesem Fall war es der Kollege Frank Tonsen, der sich nicht nur die Zeit nahm, meinen Beitrag zu lesen, sondern auch die notwendige Aufmerksamkeit besaß, meinen Fehler zu entdecken. Mehr noch: Nachdem Frank und ich eine kurze E-Mailkonversation zu diesem Thema hatten, schickte er mir sogar seine Version der Lösung, die ich in leicht angepasster Form hier abdrucke. @Frank: Vielen Dank. Derartige Reaktionen sind es, die ich an dieser Community so mag 🙂

Die Zielstellung

Die Aufgabe bestand darin, Datums- und Uhrzeitangaben, die als koordinierte Weltzeit (UTC – Coordinated Universal Time) von einem Server geliefert wurden, in unsere lokale Zeit umzurechnen. Aufgrund der in Deutschland herrschenden Regelung der Sommer- und Winterzeit kann zur UTC-Zeit jedoch nicht pauschal eine Stunde addiert werden, da die Zeitdifferenz während der Winterzeit 2 Stunden beträgt. Ich möchte die Problemlösung als benutzerdefinierte Funktion zur Verfügung stellen.

Widmen wir uns der Problemlösung.

Problemlösung

Generell kann zur Zeitverschiebung zwischen UTC und unserer Zeit in Deutschland folgendes gesagt werden:

• Unsere Sommerzeit beginnt am letzten Sonntag im März. Um 2 Uhr lokale Zeit (d. h. 1 Uhr UTC), wird die Uhr auf 3 Uhr vorgestellt. Während der Sommerzeit beträgt die Zeitverschiebung daher 2 Stunden
• Unsere Winterzeit beginnt am letzten Sonntag im Oktober. Um 3 Uhr lokale Zeit (d. h. 1 Uhr UTC), wird die Uhr auf 2 Uhr zurückgestellt. Während der Winterzeit beträgt die Zeitverschiebung daher 1 Stunde.

Für das aktuelle Jahr 2019 sieht es also wie folgt aus:

Am 31.03. (letzter Sonntag im März) wurde um 1 Uhr UTC die Zeitverschiebung von 1 Stunde, auf 2 Stunde erhöht. Dadurch folgte auf die lokale Uhrzeit 01:59:59 Uhr nicht 2:00:00 Uhr, sondern 03:00:00 Uhr:

Am 27.10. (letzter Sonntag im Oktober) wurde um 1 Uhr UTC die Zeitverschiebung von 2 Stunden, auf 1 Stund reduziert. Dadurch folgte auf die lokale Uhrzeit 02:59:59 Uhr nicht 3:00:00 Uhr, sondern 02:00:00 Uhr:

Die benutzerdefinierte Funktion, die all das berücksichtigt, sieht wie folgt aus:

Falls Du wissen möchtest, wie Du meine M-Funktionen in Deinen Projekten wiederverwenden kannst, schau bitte hier nach.

Bis zum nächsten Mal und denk dran: Sharing is caring. Wenn Dir der Beitrag gefallen hat, dann teile ihn gerne. Falls Du Anmerkungen hast, schreibe gerne einen Kommentar, oder schicke mir eine Mail an lars@ssbi-blog.de

Viele Grüße aus Hamburg,

Lars

Lars Schreiber

Lars ist Berater, Entwickler und Trainer für Microsoft Power BI. Er ist zertifizierter Power BI-Experte und Microsoft Trainer. Für sein Engagement in der internationalen Community wurde Lars seit 2017 jährlich durch Microsoft der MVP-Award verliehen. Lies hier mehr…

ssbi-blog.de

Der Beitrag Leserfrage: Umrechnung UTC-Zeit in lokale Zeit mit Power Query erschien zuerst auf THE SELF-SERVICE-BI BLOG.

When I work with customers‘ pbix files, I often deal with files with several hundred measures. At the beginning I like to get an overview which of these measures might not be used at all and could possibly be removed. For this purpose, I have developed a method to locate these measures, which I would like to share in this article. Warning: Please note that this method does not consider the measures used in the Filter Pane! So before you delete a seemingly unused measure, please check if it was used in the Pane filter. 

You can download my report file at the end of this post. The download does not require a password. If you are still asked for your OneDrive password, change your browser to Edge.

The definition of unused measures

Unused Measures are Measures that are neither used in any visualization in the .pbix file nor referenced in other Measures, calculated columns or calculated tables! So how can I identify those Measures? Let’s find the answer together…

Gather the necessary information

To find the unused measures, I need the following information:

• A list of all existing measures in the .pbix file,
• A list of the measures used in the visualizations within the .pbix file
• A list of measures referenced by other measures, calculated columns and/or calculated tables.

The logic is the following: When I remove from the all measures list those measures that are used in visualizations, I have those measures that are not used in visualizations. But they can still be referenced in other calculations (and therefore cannot be removed). So, if I hold against the list of all referencing calculations here, I finally get the measures that are not used within the .pbix file.

Retrieve a list of all measures

Since Power BI Desktop runs an instance of SQL Server Analysis Services Tabular in the background, I can use a DMV (Data Management View) to get information about my data model. You can use Power Query to gather this information using the following single line of code:

= OleDb.Query("Provider=MSOLAP.8;Data Source=localhost:61200;Update Isolation Level=2", "SELECT * FROM $SYSTEM.MDSCHEMA_MEASURES")

The result looks like this:

Be aware, that the number 61200 has to be changed in your code, as this is the process ID of the instance of Analysis Services running on your machine. The easiest way to find this number on your machine is to run DAX Studio (download it here) and connect it to your (already opened) pbix file. When you are connected, you find the desired process number in the bottom line, as you can see here:

Now that we have a list of all measures, let’s find those measures, that are used in report pages.

Retrieve a list of Measures, used in report pages in Power BI Desktop

Since May 2019 Power BI Desktop has been equipped with the extremely useful „Performance Analyzer„. This tool helps to find starting points for the optimization of slow reports. But this tool also helps me to identify those measures that are actually used on report pages. Follow these steps:

1. Create a blank page
2. Go to View → Performance Analzer and make the pane visible
3. Click on Start recording
4. Then select each page, one after another and wait until the visuals are fully loaded
5. Press Stop
6. Export the JSON file

The JSON file contains all DAX queries, generated to update the visuals when selecting the page. If a measure is used in a visual, it is represented in the DAX query and I can extract that information from the JSON file. Of course I use Power Query to do that job for me and the result looks like this:

Intermediate result

With the retrieval of all measures and the JSON file, with all measures used in visuals, I can now make a comparison and determine which measures are not used in visuals. So far, so good. However, just because a measure is not used directly in a visual, it is not automatically unused. It can be referenced in other measures, calculated columns, or calculated tables. Therefore I would like to check whether these now determined measures are really completely unused before I decide how I want to proceed with them…

Retrieve a list of calculation dependencies

The DMV, which I used for the retrieval of all existing measures, is by far not the only one available. Another useful DMV I will use to determine the measures referenced by other measures, calculated columns, or calculated tables is the following: $SYSTEM.discover_calc_dependency (see documentation of this DMV here).

I can again use Power Query to retrieve the results of this DMV like so:

= OleDb.Query("Provider=MSOLAP.8;Data Source=localhost:61200;Update Isolation Level=2", "SELECT * FROM $SYSTEM.discover_calc_dependency")

Again, the process id 61200 has to be changed to find the Analysis Services instance on your machine.

The result looks like this:

This DMV returns a clear picture of the interdependencies of calculations. For me this DMV answers the question in which measures, calculated columns and/or calculated tables my measure is referenced. If a measure is not used in any visualization and does not appear in the calculation dependencies, it is unused.

The final table

With all this information, I can now create the following table, which tells me whether a measure is used in report pages and whether it is referenced in any way:

The screenshot shows in line 5 that the measure _Distinct_Medals is not used in visuals, but is at least referenced by other measures, calculated columns and/or tables. The measure „Not_used_anywhere“ is neither referenced nor used in visuals.

Download and usage of my Measure Analysis pbix file

I loaded all the described data from DMVs and the JSON export file into a pbix file and added a (very small, but helpful) report. Admittedly, I didn’t take any trouble with the optical design. I’ll leave that to you 😉

You can download the report file here.

Open the file and edit two parameters:

• the process ID of the Analysis Services instance
• the path and name of the exported JSON file (Make sure that your string does not contain quotation marks at the beginning and at the end)

After you have clicked OK, you will see the following message in the upper part of the report page:

Click on „Apply changes“ and click on „Run“ in the following dialog, to allow the run of the DMV MDSCHEMA_MEASURES:

Then you will be asked to enter your credentials. Use „Windows“ and „Use my current credentials“:

After you have entered your credentials, Power Query prompts you to determine the privacy levels for the data source. Since in this particular case the communication between this PBIX file and the Analysis Services instance is behind the file to be analyzed, you can safely click on „Ignore Privacy Levels…“:

Click on „Apply changes“ and click on „Run“ in the following dialog, to allow the run of the DMV :

After the model refreshed, you can use the following report:

Here is a short description of the report:

• Column1: Table name and Measure name.
• Column2: If the measure was stored in a folder, you can read it here.
• Column3: DAX-Expression of the measure
• Column4: Is the measure used in a visual, somewhere in this pbix file?
• Column5: Is this measure referenced by any measure, calculated column/ table in this pbix file?

I hope that this manual will help you to bring even more order into your data models 🙂

Greetings from Germany,

Lars

Lars Schreiber

Lars ist Berater, Entwickler und Trainer für Microsoft Power BI. Er ist zertifizierter Power BI-Experte und Microsoft Trainer. Für sein Engagement in der internationalen Community wurde Lars seit 2017 jährlich durch Microsoft der MVP-Award verliehen. Lies hier mehr…

ssbi-blog.de

Der Beitrag How to identify Measures not used in your pbix file erschien zuerst auf THE SELF-SERVICE-BI BLOG.