Formelkompatibilität im DirectQuery-Modus

Artikel
07/02/2013

Die Programmiersprache Data Analysis Expression (DAX) kann verwendet werden, um Measures und andere benutzerdefinierte Formeln zu erstellen, die Sie in Tabellenmodellen und PowerPivot-Arbeitsmappen verwenden. In fast jeder Hinsicht sind die Modelle identisch, die Sie in diesen zwei Umgebungen erstellen, und Sie können die gleichen Measures, Beziehungen und KPIs usw. verwenden. Wenn Sie jedoch ein Tabellenmodell erstellen und es im DirectQuery-Modus bereitstellen, gibt es einige Einschränkungen für die Formeln, die Sie verwenden können. Dieses Thema enthält eine Übersicht über die Unterschiede und listet die Funktionen auf, die nicht im DirectQuery-Modus unterstützt werden. Des Weiteren werden die Funktionen aufgelistet, die unterstützt werden, aber andere Ergebnisse zurückgeben können.

Im Rahmen dieses Themas verwenden wir den Begriff speicherinternes Modell für beide PowerPivot-Modelle, die einen lokalen Cache verwenden, sowie für tabellarische Modelle, die vollständig in Arbeitsspeicherdaten auf einem Analysis Services-Server gehostet werden, der im tabellarischen Modus ausgeführt wird. Wir verwenden DirectQuery-Modelle, um auf Tabellenmodelle zu verweisen, die im DirectQuery-Modus bereitgestellt wurden. Informationen zum DirectQuery-Modus finden Sie unter DirectQuery-Modus (SSAS – tabellarisch).

Semantische Unterschiede
Beschreibt die Unterschiede, die entstehen könnten, wenn die gleiche Formel für den DirectQuery-Modus verwendet wird.
- Vergleiche
- Umwandlungen
- Mathematische Funktionen und arithmetische Vorgänge
- Unterstützte numerische und Datums-/Uhrzeitbereiche
- Währung
- Aggregationsfunktionen
- Textfunktionen
Im DirectQuery-Modus unterstützte Funktionen
Dieser Abschnitt listet Funktionen auf, die im DirectQuery-Modus verwendet werden können, jedoch u. U. andere Ergebnisse zurückgeben.
Im DirectQuery-Modus nicht unterstützte Funktionen
Der Abschnitt listet Funktionen auf, die nicht in im DirectQuery-Modus bereitgestellten Modellen verwendet werden können.

Funktionen, die in keiner dieser Listen enthalten sind, verhalten sich voraussichtlich identisch – unabhängig vom Modellspeicher oder Abfragemodus.

Übersicht über Unterschiede zwischen dem speicherinternen und DirectQuery-Modus

Abfragen an ein Modell, das im DirectQuery-Modus bereitgestellt wird, können andere Ergebnisse zurückgeben als bei der Bereitstellung desselben Modells im Arbeitsspeicher. Das liegt daran, dass Daten direkt aus einem relationalen Datenspeicher abgerufen und für Formeln erforderliche Aggregationen mithilfe des relevanten relationalen Moduls ausgeführt werden, anstatt das xVelocity-Modul für Datenanalyse im Arbeitsspeicher (VertiPaq) für Speicher- und Rechenvorgänge zu verwenden.

Beispielsweise behandeln bestimmte relationale Datenspeicher numerische Werte, Daten, NULL-Werte usw. auf unterschiedliche Weise.

Im Gegensatz dazu dient die DAX-Programmiersprache zum möglichst genauen Emulieren des Verhaltens von Funktionen in Microsoft Excel. Beispielsweise versucht Excel bei der Behandlung von NULL-Werten, leeren Zeichenfolgen und Werten gleich 0 unabhängig vom genauen Datentyp die optimale Antwort bereitzustellen. Folglich verhält sich das xVelocity-Modul auf die gleiche Weise. Wird jedoch ein Tabellenmodell im DirectQuery-Modus bereitgestellt, und übergibt es Formeln an eine relationale Datenquelle zur Auswertung, müssen die Daten gemäß Semantik der relationalen Datenquelle behandelt werden, wobei in der Regel eine unterschiedliche Behandlung von leeren Zeichenfolgen im Vergleich zu NULL-Werten erforderlich ist. Aus diesem Grund könnte die gleiche Formel ein anderes Ergebnis zurückgeben als im Fall der Auswertung anhand von zwischengespeicherten Daten sowie Daten, die lediglich vom relationalen Speicher abgerufen wurden.

Darüber hinaus können einige Funktionen im DirectQuery-Modus nicht verwendet werden, da andernfalls die Berechnung erfordert, dass die Daten im aktuellen Kontext an die relationale Datenquelle als Parameter gesendet werden. Beispielsweise verwenden Measures in einer PowerPivot-Arbeitsmappe oftmals Zeitintelligenzfunktionen, die auf innerhalb der Arbeitsmappe verfügbare Datumsbereiche verweisen. Derartige Formeln können im Allgemeinen nicht im DirectQuery-Modus verwendet werden.

Liste semantischer Unterschiede

Dieser Abschnitt listet die Typen der üblichen semantischen Unterschiede auf. Zudem werden Einschränkungen beschrieben, die u. U. für die Verwendung von Funktionen oder für Abfrageergebnisse gelten.

Vergleiche

Die DAX-Programmiersprache in speicherinternen Modellen unterstützt Vergleiche von zwei Ausdrücken, die in Skalarwerte verschiedener Datentypen aufgelöst werden. Modelle, die im DirectQuery-Modus bereitgestellt werden, verwenden jedoch die Datentypen und Vergleichsoperatoren des relationalen Moduls und geben daher u. U. unterschiedliche Ergebnisse zurück.

Die folgenden Vergleiche generieren immer einen Fehler, wenn sie in einer Berechnung in einer DirectQuery-Datenquelle verwendet werden:

Numerischer Datentyp im Vergleich zu einem Zeichenfolgen-Datentyp
Numerischer Datentyp im Vergleich zu einem booleschen Wert
Zeichenfolgen-Datentyp im Vergleich zu einem booleschen Wert

Im Allgemeinen toleriert die DAX-Programmiersprache mehr Datentypkonflikte in speicherinternen Modellen und versucht bis zu zweimal, eine implizite Umwandlung von Werten durchzuführen (wie in diesem Abschnitt beschrieben). An einen relationalen Datenspeicher im DirectQuery-Modus gesendete Formeln werden jedoch strenger ausgewertet, wobei die Regeln des relationalen Moduls berücksichtigt werden und mit höherer Wahrscheinlichkeit ein Fehlschlag auftritt.

Vergleiche von Zeichenfolgen und Zahlen
BEISPIEL: “2” < 3

Die Formel vergleicht eine Textzeichenfolge mit einer Zahl. Der Ausdruck lautet sowohl bei Modellen im DirectQuery-Modus als auch bei speicherinternen Modellen true.

Bei einem speicherinternen Modell lautet das Ergebnis true, da Zahlen als Zeichenfolgen implizit in einen numerischen Datentyp für Vergleiche mit anderen Zahlen umgewandelt werden. SQL wandelt auch Textzahlen implizit in Zahlen für den Vergleich mit numerischen Datentypen um.

Beachten Sie, dass dies eine Änderung des Verhaltens von der ersten Version von PowerPivot darstellt, die false zurückgeben würde, da der Text "2" stets im Vergleich zu einer Zahl als größer betrachtet wird.
Vergleich von Text mit booleschen Werten
BEISPIEL: “VERDADERO” = TRUE

Dieser Ausdruck vergleicht eine Textzeichenfolge mit einem booleschen Wert. Im Allgemeinen führt der Vergleich von einem Zeichenfolgenwert mit einem booleschen Wert bei DirectQuery-Modellen bzw. speicherinternen Modellen zu einem Fehler. Diese Regel gilt jedoch nicht, wenn die Zeichenfolge das Wort true oder false enthält. Beinhaltet die Zeichenfolge Werte vom Typ "true" oder "false", erfolgt eine Umwandlung in einen booleschen Wert. Daraufhin wird der Vergleich ausgeführt und ein logisches Ergebnis zurückgegeben.
Vergleich von NULL-Werten
BEISPIEL: EVALUATE ROW("X", BLANK() = BLANK())

Diese Formel vergleicht die SQL-Entsprechung eines NULL-Werts mit einem NULL-Wert. Sie gibt true für speicherinterne Modelle sowie DirectQuery-Modelle zurück. Eine Bereitstellung erfolgt im DirectQuery-Modell, um ein ähnliches Verhalten beim speicherinternen Modell zu gewährleisten.

Beachten Sie, dass ein NULL-Wert in Transact-SQL niemals gleich einem NULL-Wert ist. In der DAX-Programmiersprache jedoch ist ein Leerzeichen gleich einem anderen Leerzeichen. Dieses Verhalten gilt für alle speicherinternen Modelle. Im DirectQuery-Modus wird hauptsächlich die Semantik von SQL Server verwendet. In diesem Fall wird jedoch von der Semantik abgewichen, indem ein neues Verhalten für Vergleiche von NULL-Werten verwendet wird.

Umwandlungen

Es gibt in der DAX-Programmiersprache keine Umwandlungsfunktion als solche, aber implizite Umwandlungen werden bei vielen Vergleichsvorgängen sowie arithmetischen Vorgängen ausgeführt. Anhand des Vergleichsvorgangs bzw. arithmetischen Vorgangs wird der Datentyp des Ergebnisses bestimmt. Beispiel:

Boolesche Werte werden bei arithmetischen Vorgängen als numerisch betrachtet, beispielsweise als TRUE + 1. Alternativ wird die Funktion MIN für eine Spalte mit booleschen Werten angewendet. Ein NOT-Vorgang gibt ebenfalls einen numerischen Wert zurück.
Boolesche Werte werden stets als logische Werte in Vergleichen sowie bei Verwendung mit EXACT, AND, OR, && oder || betrachtet.

Umwandeln einer Zeichenfolge in einen booleschen Wert
Bei speicherinternen Modellen sowie DirectQuery-Modellen sind Umwandlungen in boolesche Werte nur bei folgenden Zeichenfolgen zulässig: "" (leere Zeichenfolge), true, false. Dabei wird eine leere Zeichenfolge in einen FALSE-Wert umgewandelt.

Umwandlungen anderer Zeichenfolgen in den booleschen Datentyp führen zu einem Fehler.
Umwandeln einer Zeichenfolge in ein Datum/eine Uhrzeit
Umwandlungen von Zeichenfolgendarstellungen für Daten und Uhrzeiten in tatsächliche datetime-Werte verhalten sich im DirectQuery-Modus auf die gleiche Weise wie bei SQL Server.

Informationen zu den Regeln für die Umwandlung des String-Datentyps in datetime-Datentypen bei PowerPivot-Modellen finden Sie unter DAX-Syntaxspezifikation für PowerPivot.

Modelle, die den speicherinternen Datenspeicher verwenden, unterstützen weniger Textformate für Datumsangaben als die entsprechenden von SQL Server unterstützten Zeichenfolgenformate. Die DAX-Programmiersprache unterstützt jedoch benutzerdefinierte Datums- und Uhrzeitformate. Weitere Informationen finden Sie unter DAX Predefined Date formats und Custom date formats.
Umwandeln von Zeichenfolgen in andere nicht-boolesche Werte
Bei der Umwandlung von Zeichenfolgen in nicht-boolesche Werte verhält sich der DirectQuery-Modus auf die gleiche Weise wie SQL Server. Weitere Informationen finden Sie unter CAST und CONVERT (Transact-SQL).
Umwandlung von Zahlen in Zeichenfolgen nicht zulässig
BEISPIEL: CONCATENATE(102,”,345”)

Die Umwandlung von Zahlen in Zeichenfolgen ist bei SQL Server nicht zulässig.

Diese Formel gibt einen Fehler in Tabellenmodellen und im DirectQuery-Modus zurück. Die Formel erzeugt allerdings in PowerPivot ein Ergebnis.
Keine Unterstützung für Umwandlungen mit zwei Versuchen in DirectQuery
Bei speicherinternen Modellen erfolgt oftmals ein zweiter Umwandlungsversuch, wenn der erste fehlgeschlagen ist. Dies geschieht nicht im DirectQuery-Modus.

BEISPIEL: TODAY() + “13:14:15”

In diesem Ausdruck weist der erste Parameter den Typ datetime und der zweite Parameter den Typ string auf. Die Umwandlungen werden jedoch im Fall der Kombination der Operanden unterschiedlich gehandhabt. DAX führt eine implizite Umwandlung von string in double aus. Bei speicherinternen Modellen versucht das Formelmodul, eine direkte Umwandlung in double vorzunehmen. Schlägt dieser Vorgang fehl, wird versucht, die Zeichenfolge in datetime umzuwandeln.

Im DirectQuery-Modus wird nur die direkte Umwandlung von string in double übernommen. Schlägt diese Umwandlung fehl, gibt die Formel einen Fehler zurück.

Mathematische Funktionen und arithmetische Vorgänge

Einige mathematische Funktionen geben im DirectQuery-Modus andere Ergebnisse zurück. Dies ist auf Unterschiede des zugrunde liegenden Datentyps oder der Umwandlungen zurückzuführen, die in Vorgängen übernommen werden können. Zudem können sich die zuvor beschriebenen Einschränkungen der zulässigen Werte auf das Ergebnis von arithmetischen Vorgängen auswirken.

Reihenfolge der Hinzufügung
Wenn Sie eine Formel erstellen, die eine Reihe von Zahlen hinzufügt, verarbeitet ein speicherinternes Modell die Zahlen u. U. in einer anderen Reihenfolge als ein DirectQuery-Modell. Liegen demnach viele sehr hohe positive Zahlen und sehr hohe negative Zahlen vor, wird möglicherweise ein Fehler in einem Vorgang zurückgegeben, und ein weiterer Vorgang wird ausgelöst.
Verwendung der POWER-Funktion
BEISPIEL: POWER(-64, 1/3)

Im DirectQuery-Modus kann die POWER-Funktion keine negativen Werte als Basis für Berechnungen mit Bruchexponenten verwenden. Dies ist das erwartete Verhalten in SQL Server.

Bei einem speicherinternen Modell gibt die Formel den Wert "-4" zurück.
Numerische Überlaufvorgänge
In Transact-SQL geben Vorgänge, die zu einem numerischen Überlauf führen, einen Überlauffehler zurück. Daher geben auch Formeln, die zu einem Überlauf führen, einen Fehler im DirectQuery-Modus zurück.

Die gleiche Formel gibt allerdings bei Verwendung in einem speicherinternen Modell eine ganze Zahl mit einer Länge von acht Byte zurück. Das liegt daran, dass das Formelmodul keine Überprüfungen für numerische Überläufe ausführt.
LOG-Funktionen mit Leerzeichen geben andere Ergebnisse zurück.
SQL Server behandelt NULL-Werte und Leerzeichen anders als das xVelocity-Modul. Daher gibt die folgende Formel einen Fehler im DirectQuery-Modus zurück, während sie beim speicherinternen Modell den Unendlichkeitswert (–inf) zurückgibt.

EXAMPLE: LOG(blank())

Die gleichen Einschränkungen gelten für die anderen logarithmischen Funktionen: LOG10 und LN.

Weitere Informationen zum blank-Datentyp in der DAX-Programmiersprache finden Sie unter DAX-Syntaxspezifikation für PowerPivot.
Division durch 0 und Division durch Leerzeichen
Im DirectQuery-Modus führt die Division durch null (0) bzw. die Division durch BLANK stets zu einem Fehler. SQL Server unterstützt nicht die Definition der Unendlichkeit, und da das natürliche Ergebnis jeder Division durch 0 die Unendlichkeit ist, entspricht das Ergebnis einem Fehler. SQL Server unterstützt jedoch die Division durch NULL-Werte, und das Ergebnis muss stets einem NULL-Wert entsprechen.

Anstelle der Rückgabe unterschiedlicher Ergebnisse für diese Vorgänge geben beide Vorgangstypen (Division durch null und Division durch einen NULL-Wert) im DirectQuery-Modus einen Fehler zurück.

Beachten Sie, dass die Division durch 0 in Excel und in PowerPivot-Modellen auch einen Fehler zurückgibt. Die Division durch ein Leerzeichen gibt ein Leerzeichen zurück.

Die folgenden Ausdrücke sind in speicherinternen Modellen gültig, schlagen jedoch im DirectQuery-Modus fehl:

1/BLANK

1/0

0.0/BLANK

0/0

Der Ausdruck BLANK/BLANK ist ein besonderer Fall, der BLANK sowohl in speicherinternen Modellen als auch im DirectQuery-Modus zurückgibt.

Unterstützte numerische und Datums-/Uhrzeitbereiche

Formeln in PowerPivot-Modellen und speicherinternen Tabellenmodellen unterliegen im Hinblick auf die maximal zulässigen Werte für reelle Zahlen und Datumsangaben den gleichen Einschränkungen wie Excel. Unterschiede können jedoch entstehen, wenn der maximale Wert von einer Berechnung oder einer Abfrage zurückgegeben wird, oder wenn Werte konvertiert, umgewandelt, gerundet oder gekürzt werden.

Werden Werte der Typen Currency und Real multipliziert, und ist das Ergebnis größer als der maximal mögliche Wert, wird im DirectQuery-Modus kein Fehler ausgelöst. Zudem wird ein NULL-Wert zurückgegeben.
Bei speicherinternen Modellen wird kein Fehler ausgelöst, aber der maximale Wert wird zurückgegeben.

Da die zulässigen Datumsbereiche für Excel und SQL Server unterschiedlich sind, kann im Allgemeinen gewährleistet werden, dass Ergebnisse nur übereinstimmen, wenn sich Datumsangaben innerhalb des üblichen Datumsbereichs befinden. Dazu gehören die folgenden Datumsangaben:

Frühestes Datum: 1. März 1900
Letztes Datum: 31. Dezember 9999

Wenn in Formeln verwendete Datumsangaben außerhalb dieses Bereichs liegen, führt entweder die Formel zu einem Fehler, oder die Ergebnisse stimmen nicht überein.

Von CEILING unterstützte Gleitkommawerte
BEISPIEL: EVALUATE ROW("x", CEILING(-4.398488E+30, 1))

Die Transact-SQL-Entsprechung für die DAX-CEILING-Funktion unterstützt nur Werte mit einer Größe von maximal 10^19. Als Faustregel gilt, dass Gleitkommawerte in bigint passen sollten.
Datepart-Funktionen mit Datumsangaben außerhalb des Bereichs
Bei Ergebnissen im DirectQuery-Modus wird gewährleistet, dass diese den Ergebnissen von speicherinternen Modellen nur entsprechen, wenn sich das als Argument verwendete Datum innerhalb des gültigen Datumsbereichs befindet. Werden diese Bedingungen nicht erfüllt, wird entweder ein Fehler ausgelöst, oder die Formel gibt in DirectQuery andere Ergebnisse zurück als im speicherinternen Modus.

BEISPIEL: MONTH(0) oder YEAR(0)

Im DirectQuery-Modus geben die Ausdrücke 12 bzw. 1899 zurück.

Bei speicherinternen Modellen geben die Ausdrücke 1 bzw. 1900 zurück.

BEISPIEL: EOMONTH(0.0001, 1)

Die Ergebnisse dieses Ausdrucks stimmen nur überein, wenn sich die als Parameter angegebenen Daten innerhalb des gültigen Datumsbereichs befinden.

BEISPIEL: EOMONTH(blank(), blank()) oder EDATE(blank(), blank())

Die Ergebnisse dieses Ausdrucks sollten im DirectQuery-Modus sowie im speicherinternen Modus gleich sein.
Kürzen von Zeitwerten
BEISPIEL: SECOND(1231.04097222222)

Im DirectQuery-Modus wird das Ergebnis auf Basis der Regeln für SQL Server gekürzt. Zudem ergibt der Ausdruck den Wert "59".

Bei speicherinternen Modellen werden die Ergebnisse jedes Zwischenvorgangs gerundet. Daher ergibt der Ausdruck den Wert "0".

Im folgenden Beispiel wird veranschaulicht, wie dieser Wert berechnet wird:
1. Der Bruch der Eingabe (0.04097222222) wird mit 24 multipliziert.
2. Der resultierende Stundenwert (0.98333333328) wird mit 60 multipliziert.
3. Der resultierende Minutenwert ist 58.9999999968.
4. Der Bruch des Minutenwerts (0.9999999968) wird mit 60 multipliziert.
5. Der resultierende zweite Wert (59.999999808) wird auf 60 aufgerundet.
6. 60 entspricht 0.
SQL-Zeitdatentyp nicht unterstützt
Bei speicherinternen Modellen wird die Verwendung des neuen Time-Datentyps nicht unterstützt. Im DirectQuery-Modus geben Formeln, die mit diesem Datentyp auf Spalten verweisen, einen Fehler zurück. Zeitdatenspalten können nicht in ein speicherinternes Modell importiert werden.

Im Fall von PowerPivot-Modellen sowie zwischengespeicherten Modellen wandelt das Modul den Zeitwert manchmal in einen zulässigen Datentyp um, und die Formel gibt ein Ergebnis zurück.

Dieses Verhalten beeinflusst alle Funktionen, die eine Datumsspalte als Parameter verwenden.

Währung

Im DirectQuery-Modus muss der Wert innerhalb des folgenden Bereichs liegen, wenn das Ergebnis eines arithmetischen Vorgangs den Typ Currency aufweist:

Minimum: -922337203685477.5808
Maximum: 922337203685477.5807

Kombinieren von Währungs- und REAL-Datentypen
BEISPIEL: Currency sample 1

Werden die Typen Currency und Real multipliziert, und ist das Ergebnis größer als 9223372036854774784 (0x7ffffffffffffc00), löst der DirectQuery-Modus keinen Fehler aus.

Im Fall eines speicherinternen Modells wird ein Fehler ausgelöst, wenn der absolute Wert des Ergebnisses größer als 922337203685477.4784 ist.
Vorgang führt zu einem Wert außerhalb des Bereichs
BEISPIEL: Currency sample 2

Wenn Vorgänge zu zwei Währungswerten einen Wert ergeben, der sich außerhalb des angegebenen Bereichs befindet, wird bei speicherinternen Modellen ein Fehler ausgegeben, jedoch nicht bei DirectQuery-Modellen.
Kombinieren von Währungsdatentypen mit anderen Datentypen
Die Division von Währungswerten durch Werte anderer numerischer Typen kann zu unterschiedlichen Ergebnissen führen.

Aggregationsfunktionen

Statistische Funktionen in einer Tabelle mit einer Zeile geben andere Ergebnisse zurück. Aggregationsfunktionen für leere Tabellen verhalten sich zudem bei speicherinternen Modellen anders als im DirectQuery-Modus.

Statistische Funktionen für eine Tabelle mit einer einzelnen Zeile
Wenn die als Argument verwendete Tabelle eine einzelne Zeile enthält, geben statistische Funktionen wie STDEV und VAR im DirectQuery-Modus einen NULL-Wert zurück.

In einem speicherinternen Modell gibt eine Formel, die STDEV oder VAR für eine Tabelle mit einer einzelnen Zeile verwendet, einen Fehler wegen einer Division durch 0 zurück.

Textfunktionen

Da relationale Datenspeicher andere Textdatentypen bereitstellen als Excel, werden bei der Suche nach Zeichenfolgen oder bei der Arbeit mit Teilzeichenfolgen möglicherweise andere Ergebnisse zurückgegeben. Die Länge der Zeichenfolgen kann auch unterschiedlich sein.

Im Allgemeinen funktioniert jede Zeichenfolgenbearbeitung, die Spalten mit fester Größe verwendet, wie Argumente über andere Ergebnisse verfügen können.

Darüber hinaus unterstützen einige Textfunktionen in SQL Server zusätzliche Argumente, die nicht in Excel bereitgestellt werden. Wenn die Formel das fehlende Argument erfordert, können andere Ergebnisse oder Fehler im speicherinternen Modell zurückgegeben werden.

Vorgänge, die ein Zeichen mit LEFT, RIGHT usw. zurückgeben, geben möglicherweise das richtige Zeichen zurück – allerdings in einer anderen Schreibweise. Alternativ werden keine Ergebnisse zurückgegeben.
BEISPIEL: LEFT([“text”], 2)

Im DirectQuery-Modus entspricht die Schreibweise des Zeichens, das zurückgegeben wird, stets dem Buchstaben, der in der Datenbank gespeichert wird. Das xVelocity-Modul verwendet jedoch zur Leistungsverbesserung einen anderen Algorithmus für die Komprimierung und Indizierung von Werten.

Standardmäßig wird die Latin1_General-Sortierung verwendet (ohne Berücksichtigung der Groß-/Kleinschreibung und mit Unterscheidung von Akzenten). Sind mehrere Instanzen einer Textzeichenfolge in Kleinbuchstaben, Großbuchstaben oder mit gemischter Schreibweise vorhanden, werden folglich alle Instanzen als gleiche Zeichenfolge betrachtet, und nur die erste Instanz der Zeichenfolge wird im Index gespeichert. Sämtliche Textfunktionen, die bei gespeicherten Zeichenfolgen ausgeführt werden, rufen den angegebenen Teil des indizierten Formulars ab. Daher gibt die Beispielformel den gleichen Wert für die gesamte Spalte zurück und verwendet dabei die erste Instanz als Eingabe.

Zeichenfolgenspeicher und -sortierung in Tabellenmodellen

Dieses Verhalten gilt auch für andere Textfunktionen, einschließlich RIGHT, MID usw.
Zeichenfolgenlänge wirkt sich auf Ergebnisse aus
BEISPIEL: SEARCH(“within string”, “sample target text”, 1, 1)

Wenn Sie mit der SEARCH-Funktion nach einer Zeichenfolge suchen und die Zielzeichenfolge länger ist als die WITHIN-Zeichenfolge, löst der DirectQuery-Modus einen Fehler aus.

Im speicherinternen Modell wird die gesuchte Zeichenfolge zurückgegeben. Dabei wird jedoch ihre Länge auf die des <WITHIN-Texts> gekürzt.

BEISPIEL: EVALUATE ROW("X", REPLACE("CA", 3, 2, "California") )

Wenn die Ersatzzeichenfolge länger ist als die Originalzeichenfolge, gibt die Formel im DirectQuery-Modus einen NULL-Wert zurück.

Bei speicherinternen Modellen entspricht das Verhalten der Formel dem von Excel. Dabei werden die Quellzeichenfolge und Ersatzzeichenfolge verkettet, wodurch CACalifornia zurückgegeben wird.
TRIM (implizit) in der Mitte von Zeichenfolgen
BEISPIEL: TRIM(“ A sample sentence with leading white space”)

Der DirectQuery-Modus übersetzt die DAX-TRIM-Funktion in die SQL-Anweisung LTRIM(RTRIM(<column>)). Folglich werden nur führende und nachfolgende Leerstellen entfernt.

Im Gegensatz dazu entfernt die gleiche Formel in einem speicherinternen Modell Leerzeichen innerhalb der Zeichenfolge – gemäß dem Verhalten von Excel.
RTRIM (implizit) mit Verwendung der LEN-Funktion
BEISPIEL: LEN(‘string_column’)

Wie bei SQL Server entfernt auch der DirectQuery-Modus Leerstellen am Ende der Zeichenfolgenspalten automatisch (Ausführung der impliziten RTRIM-Funktion). Daher können Formeln, die die LEN-Funktion verwenden, andere Werte zurückgeben, wenn die Zeichenfolge nachfolgende Leerzeichen aufweist.
Der speicherinterne Modus unterstützt zusätzliche Parameter für SUBSTITUTE.
BEISPIEL: SUBSTITUTE([Title],”Doctor”,”Dr.”)

BEISPIEL: SUBSTITUTE([Title],”Doctor”,”Dr.”, 2)

Im DirectQuery-Modus können Sie nur die Version dieser Funktion verwenden, die über drei (3) Parameter verfügt: ein Verweis auf eine Spalte, der alte Text und der neue Text. Wenn Sie die zweite Formel verwenden, wird ein Fehler ausgelöst.

Bei speicherinternen Modellen können Sie einen optionalen vierten Parameter verwenden, um die Instanznummer der zu ersetzenden Zeichenfolge anzugeben. Beispielsweise können Sie nur die zweite Instanz ersetzen usw.
Einschränkungen der Zeichenfolgenlänge für REPT-Vorgänge
Bei speicherinternen Modellen muss die Länge einer Zeichenfolge, die sich aus einem REPT-Vorgang ergibt, weniger als 32.767 Zeichen umfassen.

Diese Einschränkung gilt nicht für den DirectQuery-Modus.
Vorgänge für Teilzeichenfolgen geben abhängig von Zeichentyp andere Ergebnisse zurück
BEISPIEL: MID([col], 2, 5)

Wenn der Eingabetext varchar oder nvarchar lautet, ist das Ergebnis der Formel immer gleich.

Entspricht der Text jedoch einem Zeichen mit fester Länge, und ist der Wert für <num_chars> größer als die Länge der Zielzeichenfolge, wird im DirectQuery-Modus am Ende der Ergebniszeichenfolge ein Leerzeichen hinzugefügt.

Bei einem speicherinternen Modell endet das Ergebnis beim letzten Zeichenfolgenzeichen (ohne Auffüllung).

Im DirectQuery-Modus unterstützte Funktionen

Die folgenden DAX-Funktionen können im DirectQuery-Modus verwendet werden, allerdings mit den im vorherigen Abschnitt beschriebenen Qualifikationen.

Textfunktionen

CONCATENATE

FIND

LEFT

LEN

MID

REPLACE

REPT

RIGHT

SUBSTITUTE

TRIM

Statistische Funktionen

COUNT

STDEV.P

STDEV.S

STDEVX.P

STDEVX.S

VAR.P

VAR.S

VARX.P

VARX.S

Datums-/Uhrzeitfunktionen

DATE

EDATE

EOMONTH

DATE

TIME

SECOND

Mathematische Funktionen und Zahlenfunktionen

CEILING

LOG

LOG10

POWER

DAX-Tabellenabfragen

Es gibt einige Einschränkungen, wenn Sie Formeln anhand eines DirectQuery-Modells auswerten, indem Sie DAX-Tabellenabfragen verwenden. DirectQuery unterstützt in einer ORDER BY-Klausel keinen zweimaligen Verweis auf dieselbe Spalte. Die entsprechende Transact-SQL-Anweisung kann nicht erstellt werden, und die Abfrage schlägt fehl.

Bei einem speicherinternen Modell hat das Wiederholen der ORDER BY-Klausel keine Auswirkung auf die Ergebnisse.

Im DirectQuery-Modus nicht unterstützte Funktionen

Einige DAX-Funktionen werden nicht in Modellen unterstützt, die im DirectQuery-Modus bereitgestellt werden. Wird eine bestimmte Funktion nicht unterstützt, kann dies auf mindestens einen der folgenden Gründe zurückgeführt werden:

Das zugrunde liegende relationale Modul kann keine Berechnungen ausführen, die gleichwertig mit denen des xVelocity-Moduls sind.
Die Formel lässt sich nicht in einen entsprechenden SQL-Ausdruck umwandeln.
Die Leistung des umgewandelten Ausdrucks und die resultierenden Berechnungen sind nicht akzeptabel.

Die folgenden DAX-Funktionen können in DirectQuery-Modellen nicht verwendet werden.

Pfadfunktionen

PATH

PATHCONTAINS

PATHITEM

PATHITEMREVERSE

PATHLENGTH

Sonstige Funktionen

COUNTBLANK

FIXED

FORMAT

RAND

RANDBETWEEN

Zeitintelligenzfunktionen: Start- und Enddaten

DATESQTD

DATESYTD

DATESMTD

DATESQTD

DATESINPERIOD

TOTALMTD

TOTALQTD

TOTALYTD

DATESINPERIOD

SAMEPERIODLASTYEAR

PARALLELPERIOD

Zeitintelligenzfunktionen: Bilanzen

OPENINGBALANCEMONTH

OPENINGBALANCEQUARTER

OPENINGBALANCEYEAR

CLOSINGBALANCEMONTH

CLOSINGBALANCEQUARTER

CLOSINGBALANCEYEAR

Zeitintelligenzfunktionen: Vorherige und kommende Zeiträume

PREVIOUSDAY

PREVIOUSMONTH

PREVIOUSQUARTER

PREVIOUSYEAR

NEXTDAY

NEXTMONTH

NEXTQUARTER

NEXTYEAR

Zeitintelligenzfunktionen: Zeiträume und Berechnungen im Verlauf von Zeiträumen

STARTOFMONTH

STARTOFQUARTER

STARTOFYEAR

ENDOFMONTH

ENDOFQUARTER

ENDOFYEAR

FIRSTDATE

LASTDATE

DATEADD

Siehe auch

Konzepte

DirectQuery-Modus (SSAS – tabellarisch)

Freigeben über