You can download all code samples from here. If you already have my Power Query editor for Notepad++ (or want to build it) you can open the file in Notepad++. Otherwise open it in a simple text editor and paste it into the Advanced Editor of Power Query or Power BI Desktop.

The global environment

In the last two posts (Part1 and Part2) we discussed environments of expressions in records and let expressions. In addition to these very individual environments, there is (almost) always a global environment. Take a look at the following expression and its result:

There are two reasons, why the expression Table.FromRecords({[A=1, B=2],[A=3, B=4]}) returns a table with two columns and two rows:

1. The function Table.FromRecords() (like any other native M function) is part of the global environment.
2. The expression Table.FromRecords({[A=1, B=2],[A=3, B=4]}) is evaluated with the global environment being part of the expression’s environment.

That might sound a bit strange. But you will see later, when we talk about the function Expression.Evaluate(), what happens, if there is no global environment. Then come back to this line and read it one more time

What’s part of the global environment?

Knowing, that there is a global environment might make you think what is part of it. If you want to see the components of the global environment, you can use the (so called) intrinsic variable #shared. #shared returns a record containing all names and values of all the queries (tables, constants, records, lists, native M functions, custom functions, etc.) in the current Excel/ Power BI Desktop file.

All these components are part of the global environment. This is the reason why you can reference a Power Query queries‘ result in another Power Query query. You can’t influence #shared in Power BI Desktop/ Power Query by writing code, but you can create new queries, which then automatically belong to #shared. Now, knowing what the global environment is and knowing about #shared, let’s continue with the function Expression.Evaluate(), which can define its own environment.

Expression.Evaluate()

This M function evaluates a text expression and returns the evaluated value. You can find the official documentation of this function here. Before we move on, we have to give big credits to Chris Webb for his excellent post about Expression.Evaluate(), which very much enlightened us . Take a look at this very simple example of how to use this function:

Even though „1 + 1“ is a text, the function evaluates the expression and returns the value 2. This can get pretty handy, when you for example have to create the code to be evaluated on the fly.

Expression.Evaluate() and the global environment

Now let us get back to our former expression Table.FromRecords({[A=1, B=2],[A=3, B=4]}) and evaluate this inside Expression.Evaluate():

Instead of returning the expected table, we get the error message, that the function Table.FromRecords() doesn’t exist in the current context. Replace current context by current environment and it gets a bit clearer: The required function doesn’t exist in the current environment. Expression.Evaluate() is not evaluated in the global environment and this is why it doesn’t even know the function Table.FromRecord() exists. Its environment is empty.

How can we resolve that? Let’s take a look at the syntax of Expression.Evaluate():

Expression.Evaluate(expression as text, optional environment as [...]) as any

The function has a second, optional parameter: Environment. This parameter has to be a record. But how to define the environment with a record? There is good news for you. You already know a variable, that contains all the M functions and returns a record: #shared! Using #shared as second parameter resolves the problem:

But not all environmental problems come from the global environment.

Expression.Evaluate() and non global environments

The global environment is not the only possible environmental problem, when it comes to Expression.Evaluate(). Take a look at the following script:

The error message is the same (only the error code is slightly different), as in the example before, but this time it’s not about the global environment, but about the environment of the let expression. The expression behind variable Source cannot access the variables MyVariableA and MyVariableB, because the environment within the Expression.Evaluate() function is empty. You might think, that we could resolve this problem the same way we did last time: by adding #shared?! Unfortunately this is no solution. Even if you include #shared, you get the following error message:

The variables MyVariableA and MyVariablesB are not part of #shared, as this intrinsic variable only includes the results of queries, not single variables within the queries. So, how could a solution look like? Take a look at the following script:

As you can see this script delivers the desired result: 3! But honestly, what does this [MyVariableA = MyVariableA, MyVariableB = MyVariableB] mean? This is something we learned from Chris and the next screenshot will unravel the mystery:

The definition in squared brackets pulls the outer variables MyVariableA and MyVariableB into the environment of the Expression.Evaluate() function and creates a connection between those outer variables and the variables from inside the Expression.Evaluate() function. Usually the inner and outer variables have the same name (e. g. MyVariableA = MyVariableA) what made it hard to understand expresions like [MyVariableA = MyVariableA], but now you know what this syntax is used for. Please notice, that the order plays an important role: It has to be [InnerVariable = OuterVariable]. If you try to change the order, you will get an error message.

Expression.Evaluate with combined global and non global environments

You have seen how to define the global environment inside Expression.Evaluate (by adding #shared) and how to add variables from the same query to the Expression.Evaluate function. Now let’s push it a bit further. What if you need both combined? Let’s say, you want to access outer variables and additionally you want to use a native M function, to calculate a sum of a list:

We need to get the list MyListA inside the environment of Expression.Evaluate(). Additionally we need to add the global environment (#shared) to Expression.Evaluate(), because otherwise List.Sum() does not exist. We’ve got to do that in three steps:

1. Creating a record, that does the connection between inner and outer variables
2. Combining that record with #shared (the global environment), which is a record itself
3. Adding that new record as second parameter of Expression.Evaluate()

As you can see this leads to the desired result: 3! But you can shorten the code, by creating the combined environment record inside Expression.Evaluate():

Switching between Global and non global Environments

Imagine the following scenario: You have a query, that is called MyValue, which contains the value 12.

Now you write another query, which contains a variable (step) with the same name MyValue, that has the value 1.

How can you ensure, that the Result of Query1 refers to Query MyValue and not to the step MyValue, or in other words: How can Query1 return the value 12 instead of 1? With environments:

Because the query MyValue is part of the global environment, we can use Expression.Evaluate() and use #shared as environment. That way the query MyValue is evaluated, and not the variable (step) MyValue

Expression.Evaluate in a calculated column

Let’s say you have the following table and you need to calculate the sum of both columns by using Expression.Evaluate(). This could be the case, when you try to rebuild the example from this blog post from Imke.

The upcoming error message tells us, that the identifier is unknown, or in other words, [Column1] and [Column2] are not part of the environment of the Expression.Evaluate() statement. Inside a table, the underscore „_“ represents the current row, when working with line-by-line operations. The error can be fixed, by adding [_=_] to the environment of the Expression.Evaluate() function. This adds the current row of the table, in which this formula is evaluated, to the environment of the statement, which is evaluated inside the Expression.Evaluate() function.

At the time of writing Expression.Evaluate() is one of two native M functions, which is able to define its own environment. The other one is SqlExpression.ToExpression()…

SqlExpression.ToExpression()

SqlExpression.ToExpression() is no new native M function. It exists for a long time now. Unfortunately this function has an official documentation which only covers the syntax of the function:

SqlExpression.ToExpression(sql as text, environment as record) as text

Honestly we do not know more about this function, but we wanted to name it here, because it can define its own environment. So if you know more about it, feel free to comment below this post

Quick recap

What did we see so far?

• There is a global environment, which exists (almost always) in parallel to the individual environments of each expression. This is the reason why native M functions and other Power Query queries can be accessed in expressions
• #shared is a variable, returning a record with all the components of the global environment in the current Excel/ Power BI Desktop file
• There exist two native M functions, which can define their own environment: Expression.Evaluate(Expression, optional Environment) and SqlExpression.ToExpression(Sql-Expression, optional Environment)
• Without the optional second parameter, the environment of Expression.Evaluate() is empty. That’s why, unless you define the environment correctly, this function can neither access any variable from inside the Power Query query nor use a native or custom M function.
• The second parameter creates the environment for the defined expressions within the first parameter of the function (e. g. #shared, other variables within the Power Query query, etc.). The second parameter follows the pattern [inner variable = outer variable].
• If you want, that the environment of your Expression.Evaluate() function consists of the global environment ( e. g. to use native m functions) and an outer variable, then you can do that the following way: Use Record.Combine([inner variable = outer variable], #shared) and then use this as second parameter of the Expression.Evaluate() function.
• If you are using Expression.Evaluate() in a calculated column and want to reference columns of the current table, you need to use [_=_] as environment, to pull the current row inside the environment of the Expression.Evaluate() function.

The next post will discuss custom M functions and their environments. Stay tuned

Regards from Germany,

Lars & Imke

I write my posts for you, the reader. Please take a minute and rate the following 3 categories and press „submit“, to help me write even better posts. Thank you

[yasr_visitor_multiset setid=2]

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 The Environment concept in M for Power Query and Power BI Desktop, Part 3 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 Ausgangssituation

Gegeben ist die folgende Tabelle, die Kosten je Abteilung, Kostenart und Monat ausweist:

Die Vertikale

In der Vertikalen sind sowohl die Abteilungen vermerkt (fett gedruckt), als auch die Kostenarten je Abteilung. Sowohl die Kostenarten, als auch die Abteilungen können mit jeder neuen Veröffentlichung dieser Tabelle vollkommen anders aussehen.

Die Horizontale

In der Horizontalen sind unterschiedliche Formen von zeitlichen Angaben zu finden. In den meisten Fällen handelt es sich um Monate, jedoch können es auch Quartale („Q1 17“), Halbjahre, oder andere zeitliche Aggregate sein. Auch hier steckt viel Flexibilität drin und der Spaltenaufbau kann mit jeder neuen Veröffentlichung variieren.

Das Zielbild

Das Zielbild besteht darin, aus der Spalte Datum zwei Spalten Abteilung und Kostenart abzuleiten. Die folgende Abbildung visualisiert den Übergang von der Ausgangssituation zur Zielstellung.

Die Problemstellung

Ich hatte bereits erwähnt, dass sämtliche Kostenarten und Abteilungsbezeichnungen exemplarischer Natur sind und sich jederzeit ändern können. Daher kann ich für meine Lösung nicht auf die fixe Tabellenstruktur setzen. Was beim Auftreten einer Abteilungsbezeichnung in der Urpsrungstabelle besonders ist, ist die Tatsache, dass alle weiteren Zellen in der entsprechenden Zeile keine Werte (also NULL-Werte) ausweisen (in der vorherigen Abbildung rot markiert). Um eine Möglichkeit zu haben, die Abteilungsbezeichnungen zu identifieren, ist es sinnvoll diejenigen Zeilen zu identifizieren, die in allen Spalten außer der Spalte Datum (hier stehen ja die Kostenarten und Abteilungsbezeichnungen drin) NULL-Werte ausweisen. Wichtig hierbei ist es sich in Erinnerung zu rufen, dass auch die Spalten jederzeit ihren Aufbau ändern können. Meine Lösung muss also Spalten-flexibel sein.

Der Lösungsansatz

Die Idee ist, eine neue Spalte zu kalkulieren, die dynamisch prüft, ob alle existierenden Spalten, außer der Spalte Datum (in ihr befinden sich die Kostenarten und Abteilungsbezeichnungen) leer sind, also einen null-Wert ausweisen. Das Zwischenergebnis könnte demnach wie folgt aussehen:

Auf Basis dieser Prüfspalte, kann ich leicht die Spalten Abteilung und Kostenart erzeugen, doch wie erzeuge ich diese Prüfspalte?

Die Erstellung der Prüfspalte

Die Erstellung der Prüfspalte untergliedert sich in 3 inhaltlich voneinander trennbare Schritte:

1. Ermittlung der zu prüfenden Spalten
2. Aufbau der Prüffunktion
3. Evaluierung der erstellten Prüffunktion

Diese drei Schritte werde ich nun erläutern.

Ermittlung der zu prüfenden Spalten

Was ich weiß ist, dass die Spalte Datum die einzig fixe Spalte ist und, dass ich alle anderen Spalten auf NULL-Werte untersuchen möchte. Ich kann die zu prüfenden Spalten demnach wie folgt dynamisch per Formel ermitteln:

List.Difference(Table.ColumnNames(MeineTabelle), {"Datum"})

Diese Formel arbeitet wie folgt:

1. Table.ColumnNames(MeineTabelle) gibt eine Liste aller Spaltenbezeichnungen von Tabelle MeineTabelle zurück. MeineTabelle ist hierbei der Schritt in meinem Power Query Skript, der diejenige Tabelle beinhaltet, auf der ich die entsprechende Analyse betreiben will.
2. {"Datum"} ist eine Liste, die einzig und allein die Bezeichnung der fixen Spalte Datum beinhaltet.
3. List.Difference() ist eine Funktion, die den Unterschied zwischen zwei Listen als Liste zurückgibt. Dieser Funktion übergebe ich die Listen {"Datum"} (also die einzige Spalte, die nicht auf NULL-Werte geprüft werden soll) und Table.ColumnNames(MeineTabelle),  welche alle Spaltenbezeichnungen der Tabelle MeineTabelle beinhaltet. Als Ergebnis wird eine Liste zurückgegeben, die alle Spaltenbezeichnungen beinhaltet, außer Datum.

Auf diese Weise erhalte ich eine Liste der zu prüfenden Spaltenbezeichnungen, unabhängig davon, ob die Tabelle breiter oder schmaler wird. Jetzt, da ich weiß, welche Spalten zu prüfen sind, gilt es eine dynamische Formel zu entwerfen, die die Basis der Prüfung darstellt.

Aufbau der Prüffunktion

Für die Erstellung und Evaluierung der Prüffunktion, habe ich mich bei einem Artikel meiner guten Freundin Imke bedient. Zunächst konvertiere ich die Liste der zu prüfenden Spalten in eine Tabelle.

Diese Konvertierung ist notwendig, da ich ein paar berechnete Spalten hinzufügen möchte und berechnete Spalten nur zu Tabellen, nicht aber zu Listen hinzugefügt werden können. Nun erzeuge ich eine neue Spalte, die um den jeweiligen Spaltennamen eckige Klammern setzt und „= null“ ergänzt. Dies ist der erste Bestandteil des Formeltextes.

Nun kommt der zweite Schritt, der den Formeltext vervollständigt. Ich füge eine weitere berechnete Spalte hinzu und ermittle dessen Inhalt, wie in folgendem Screenshot dargestellt:

Die Funktion Text.Combine() benötigt als ersten Parameter eine Liste von Texten, die miteinander verknüpft werden sollen. Als zweiten, optionalen Parameter wird ein Text benötigt, der als Separator der zu verknüpfenden Texte dient. Ich möchte in diesem Beispiel erreichen, dass alle in Spalte FormelTeil1 befindlichen Einträge mit einander verknüpft werden und dabei durch den Text “ and „ getrennt werden. Der Funktion Text.Combine() die Spalte FormelTeil1 als ersten Parameter zu übergeben, ist nicht ausreichend, weil es sich hierbei nicht um eine Liste handeln würde, die von der Funktion jedoch verlangt wird. Ich wandle die Spalte in eine Liste um, indem ich nicht allein auf die Spalte verweise (mit [FormelTeil1]), sondern vor den Spaltennamen noch den Namen des vorangegangenen Schrittes setze: SpalteFormelTeil1[FormelTeil1]. Da der Schritt SpalteFormelTeil1 eine Tabelle zurückgibt, fungiert der Name des Schrittes als Tabellenname. Nutze ich die Syntax Tabelle[Spalte] interpretiert Power Query dies als Liste.

Auf diese Weise erhalte ich nun eine Spalte, die dieselbe Formel in jeder Zelle ausweist. Um auf eine dieser Formeln als Text zugreifen zu können, ergänze ich die in der Formelleiste befindliche Formel lediglich um den rot markierten Bestandteil:

Damit greife ich in der Spalte FormelKomplett auf den Inhalt der ersten Zelle zu. Wie Du siehst, ist Power Query beim Adressieren seiner Zeilen Null-basiert. Will ich also auf die erste Zelle zugreifen, so nutze ich die Syntax {0} und nicht {1}.

An dieser Stelle habe ich die Prüffunktion als Text in einem Schritt gespeichert. Nun gilt es, diese Formel auch zu evaluieren, d. h. auszuführen und mit dessen Ergebnis weiterzuarbeiten.

Evaluierung der erstellten Prüffunktion

Nachdem die Prüfformel als Text vorliegt, will ich diese nun für meine Prüfung nutzen. Ich füge eine benutzerdefinierte Spalte hinzu und nutze die Formel          Expression.Evaluate(FormelAlsText, [_=_]):

Dieser Formel übergebe ich zwei Parameter:

• FormelAlsText: FormelAlsText ist der Name des Schrittes, in welchem ich die dynamisch erzeugte Prüfformel als Text gespeichert habe. Diese möchte ich nun evaluieren lassen.
• [_=_]: Dies ist der zweite Parameter der Funktion Expression.Evaluate(), der die Environment der Funktion bestimmt. Die Environment ist ein fortgeschrittenes Konzept der Sprache M, das ich in der Beitragsserie The Environment concept in M for Power Query and Power BI Desktop behandle. An dieser Stelle soll es ausreichen zu wissen, dass über [_=_] der Bezug zwischen der in Expression.Evaluate() zu evaluierenden Formel und der jeweiligen Zeile der Tabelle, in welche ich gerade die Spalte IsNULL? einbaue, hergestellt wird. Ohne diesen Parameter kann die Formel nicht evaluiert werden.

Expression.Evaluate() nimmt nun diese beiden Parameter und führt die als Text übergebene Formel aus. Die Evaluierung dieser Formel führt zur Prüfspalte IsNULL?. Für den Fall, dass die untersuchten Spalten in der entsprechenden Zeile alle NULL sind, führt dies in Spalte IsNULL? zu TRUE, sonst zu FALSE. Auf Basis der TRUE- und FALSE-Werte kann ich nun relativ einfach Abteilungen und Kostenarten voneinander getrennt in separaten Spalten auszuweisen.

Die fertige Lösung

Der Grund für die Erzeugung der Prüfspalte, ist die Tatsache, dass ich die beiden Spalten Abteilung und Kostenart auf Basis eines Kriteriums aus der Spalte Datum ableiten muss. Mit einem Klick auf Spalten hinzufügen → Bedingte Spalte kann ich die Kalkulation des folgenden Screenshots nachbauen:

Für den Fall, dass der Wert in Spalte IsNULL? TRUE ist, handelt es sich um eine Abteilung, die ich dann in die neue Spalte übernehmen möchte. Wichtig ist hierbei, dass im Sonst-Fall (im Screenshot Anderfalls benannt), ein NULL-Wert zurückgebeben wird. Auf diese Weise kann man über Transformieren → Ausfüllen → nach unten die NULL-Werte durch die darüberliegende Abteilungsbezeichnung überschreiben, so dass in jeder Zeile dieser Spalte die korrekte Abteilung vermerkt ist. Im Anschluss kann ich auf eine sehr ähnliche Weise die Kostenart in eine separate Spalte schreiben:

An dieser Stelle finde ich die gewünschte Kostenart vor, wenn der Wert in Spalte IsNULL? FALSE ist. Nachdem ich anschließend die NULL-Werte aus Spalte Kostenart ausgefiltert habe und die Sortierung der Spalten nach meinem Bedarf angepasst habe, kann ich nun auch die Prüfspalte entfernen und das finale Ergebnis sieht wie folgt aus:

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

Ich schreibe meine Beiträge für Dich, den Leser. Bitte schenke mir eine Minute Deiner Zeit und bewerte die folgenden Kategorien, um mir zu helfen meine Beiträge so gut wie möglich zu schreiben. Danke

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 NULL-Werte in Tabellen mit variablen Spalten finden erschien zuerst auf THE SELF-SERVICE-BI BLOG.