DAX-Formelkompatibilität im DirectQuery-Modus (SSAS 2014)

Die Dax-Sprache (Data Analysis Expression Language) kann verwendet werden, um Measures und andere benutzerdefinierte Formeln für die Verwendung in Tabellarischen Analysis Services-Modellen, PowerPivot-Datenmodellen in Excel-Arbeitsmappen und Power BI Desktop-Datenmodellen zu erstellen. In den meisten Fällen sind die Modelle, die Sie in diesen Umgebungen erstellen, identisch, und Sie können dieselben Measures, Beziehungen und KPIs usw. verwenden. Wenn Sie jedoch ein Tabellarisches Analysis Services-Modell 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 diese Unterschiede, listet die Funktionen auf, die im Tabellenmodell von SQL Server 2014 Analysis Services auf Kompatibilitätsebene 1100 oder 1103 und im DirectQuery-Modus nicht unterstützt werden, und listet die funktionen auf, die unterstützt werden, aber möglicherweise unterschiedliche Ergebnisse zurückgeben.

In diesem Thema verwenden wir den Begriff In-Memory-Modell, um auf tabellarische Modelle zu verweisen, die vollständig im Arbeitsspeicher zwischengespeicherte Daten enthalten und auf einem Analysis Services-Server im Tabellarmodus ausgeführt werden. Wir verwenden DirectQuery-Modelle , um auf Tabellarische Modelle zu verweisen, die erstellt und/oder im DirectQuery-Modus bereitgestellt wurden. Informationen zum DirectQuery-Modus finden Sie unter DirectQuery Mode (SSAS Tabular).

Unterschiede zwischen Speicher und DirectQuery-Modus

Abfragen für ein modell, das im DirectQuery-Modus bereitgestellt wird, können unterschiedliche Ergebnisse zurückgeben als dasselbe Modell, das im Arbeitsspeichermodus bereitgestellt wird. Dies liegt daran, dass mit DirectQuery Daten direkt aus einem relationalen Datenspeicher abgefragt werden und Aggregationen, die von Formeln benötigt werden, mithilfe des relevanten relationalen Moduls ausgeführt werden, anstatt das xVelocity-Modul (VertiPaq) für Speicher und Berechnung zu verwenden.

Beispielsweise gibt es Unterschiede in der Art und Weise, wie bestimmte relationale Datenspeicher numerische Werte, Datumsangaben, Nullen usw. verarbeiten.

Im Gegensatz dazu soll die DAX-Sprache das Verhalten von Funktionen in Microsoft Excel möglichst genau emulieren. Wenn Sie z. B. Nullen, leere Zeichenfolgen und Nullwerte behandeln, versucht Excel, unabhängig vom genauen Datentyp die beste Antwort bereitzustellen, und daher funktioniert das xVelocity-Modul gleich. Wenn jedoch ein tabellarisches Modell im DirectQuery-Modus bereitgestellt und Formeln zur Auswertung an eine relationale Datenquelle übergeben wird, müssen die Daten entsprechend der Semantik der relationalen Datenquelle behandelt werden, die in der Regel eine unterschiedliche Behandlung leerer Zeichenfolgen im Vergleich zu Nullen erfordert. Aus diesem Grund kann dieselbe Formel ein anderes Ergebnis zurückgeben, wenn sie für zwischengespeicherte Daten und für Daten ausgewertet wird, die ausschließlich aus dem relationalen Speicher zurückgegeben werden.

Darüber hinaus können einige Funktionen im DirectQuery-Modus nicht verwendet werden, da für die Berechnung die Daten im aktuellen Kontext als Parameter an die relationale Datenquelle gesendet werden müssen. Beispielsweise verwenden Berechnungen in einer PowerPivot-Arbeitsmappe häufig Zeitintelligenzfunktionen, die auf in der Arbeitsmappe verfügbare Datumsbereiche verweisen. Solche Formeln können in der Regel nicht im DirectQuery-Modus verwendet werden.

Semantische Unterschiede

In diesem Abschnitt werden die Arten von semantischen Unterschieden aufgeführt, die Sie erwarten können, und beschreibt alle Einschränkungen, die für die Verwendung von Funktionen oder für Abfrageergebnisse gelten können.

Vergleiche

DAX in Speichermodellen unterstützt Vergleiche von zwei Ausdrücken, die zu skalaren Werten unterschiedlicher Datentypen aufgelöst werden. Modelle, die im DirectQuery-Modus bereitgestellt werden, verwenden jedoch die Datentypen und Vergleichsoperatoren des relationalen Moduls und geben daher möglicherweise unterschiedliche Ergebnisse zurück.

Die folgenden Vergleiche geben immer einen Fehler zurück, wenn sie in einer Berechnung mit einer DirectQuery-Datenquelle verwendet werden:

• Numerischer Datentyp im Vergleich zu einem beliebigen Zeichenfolgendatentyp

• Numerischer Datentyp im Vergleich zu einem booleschen Wert

• Ein beliebiger Zeichenfolgendatentyp im Vergleich zu einem booleschen Wert

Im Allgemeinen ist DAX gegenüber Datentypkonflikten in In-Memory-Modellen nachsichtiger und nimmt maximal zweimal eine implizite Umwandlung von Werten vor, wie in diesem Abschnitt beschrieben. Formeln, die an einen relationalen Datenspeicher im DirectQuery-Modus gesendet werden, werden jedoch strenger ausgewertet, entsprechend den Regeln des relationalen Systems, und können eher fehlschlagen.

Vergleiche von Zeichenfolgen und Zahlen
BEISPIEL: "2" < 3

Die Formel vergleicht eine Textzeichenfolge mit einer Zahl. Der Ausdruck ist sowohl im DirectQuery-Modus als auch in Speicher-Modellen wahr.

In einem Speichermodell ist das Ergebnis wahr , da Zahlen als Zeichenfolgen implizit in einen numerischen Datentyp für Vergleiche mit anderen Zahlen umgeformt werden. SQL wandelt Textnummern auch implizit als Zahlen für den Vergleich zu numerischen Datentypen um.

Beachten Sie, dass dies eine Verhaltensänderung von der ersten Version von PowerPivot darstellt, die "false" zurückgeben würde, da der Text "2" immer größer als eine beliebige Zahl wird.

Vergleich von Text mit Boolean
BEISPIEL: "VERDADERO" = TRUE

Dieser Ausdruck vergleicht eine Textzeichenfolge mit einem booleschen Wert. Im Allgemeinen führt der Vergleich eines Zeichenfolgenwerts zu einem booleschen Wert für DirectQuery oder In-Memory Modelle zu einem Fehler. Die einzigen Ausnahmen von der Regel sind, wenn die Zeichenfolge das Wort "true " oder das Wort "false" enthält. Wenn die Zeichenfolge einen der wahr- oder falsch-Werte enthält, wird eine Konvertierung in Boolean durchgeführt, und der Vergleich erfolgt, sodass das logische Ergebnis zurückgegeben wird.

Vergleich von Nullen
BEISPIEL: EVALUATE ROW("X", BLANK() = BLANK())

Mit dieser Formel wird die SQL-Entsprechung einer Null mit einem Nullwert verglichen. Es gibt wahr in Arbeitsspeicher- und DirectQuery-Modellen zurück; im DirectQuery-Modell wird eine Vorkehrung getroffen, um ein ähnliches Verhalten wie im Arbeitsspeichermodell zu gewährleisten.

Beachten Sie, dass in Transact-SQL nie ein Nullwert gleich einem Nullwert ist. In DAX ist jedoch ein Leerzeichen gleich einem anderen leeren Wert. Dieses Verhalten ist für alle In-Memory-Modelle identisch. Es ist wichtig zu beachten, dass der DirectQuery-Modus die meisten der Semantiken von SQL Server verwendet; in diesem Fall zeigt er jedoch ein neues Verhalten bei NULL-Vergleichen.

Umwandlungen

In DAX gibt es keine Umwandlungsfunktion, aber implizite Umwandlungen werden in vielen Vergleichs- und arithmetischen Vorgängen ausgeführt. Es handelt sich um den Vergleichs- oder arithmetischen Vorgang, der den Datentyp des Ergebnisses bestimmt. Beispiel:

• Boolesche Werte werden in arithmetischen Vorgängen als numerisch behandelt, z. B. TRUE + 1 oder die Funktion MIN, die auf eine Spalte boolescher Werte angewendet wird. Ein NOT-Vorgang gibt auch einen numerischen Wert zurück.

• Boolesche Werte werden immer als logische Werte bei Vergleichen und bei der Verwendung mit EXACT, UND, ODER, && oder || behandelt.

Umwandeln von Zeichenfolge in Boolean
In In-Memory- und DirectQuery-Modellen sind Umwandlungen in Boolesche Werte nur aus diesen Zeichenfolgen zulässig: "" (leere Zeichenfolge), "true", "false"; dabei wird eine leere Zeichenfolge in einen false-Wert umgewandelt.

Das Umwandeln einer beliebigen anderen Zeichenfolge in den booleschen Datentyp führt zu einem Fehler.

Umwandeln von Zeichenfolge in Datum/Uhrzeit
Im DirectQuery-Modus verhalten sich Umwandlungen von Zeichenfolgendarstellungen von Datums- und Uhrzeitangaben zu tatsächlichen Datetime-Werten genauso wie in SQL Server.

Informationen zu den Regeln für Umwandlungen von Zeichenfolgen in Datetime-Datentypen in PowerPivot-Modellen finden Sie in der DAX-Syntaxreferenz.

Modelle, die den Speicher im Arbeitsspeicher verwenden, unterstützen einen begrenzteren Textbereich für Datumsangaben als die Zeichenfolgenformate für Datumsangaben, die von SQL Server unterstützt werden. DAX unterstützt jedoch benutzerdefinierte Datums- und Uhrzeitformate.

Umwandeln von Zeichenfolgen in andere nicht boolesche Werte
Beim Umwandeln von Zeichenfolgen in nicht boolesche Werte verhält sich der DirectQuery-Modus wie SQL Server. Weitere Informationen finden Sie unter CAST und CONVERT (Transact-SQL).

Umwandeln von Zahlen in Zeichenkette ist nicht erlaubt
BEISPIEL: CONCATENATE(102,",345")

Das Umwandeln von Zahlen in Zeichenfolgen ist in SQL Server nicht zulässig.

Diese Formel gibt einen Fehler in tabellarischen Modellen und im DirectQuery-Modus zurück. Die Formel erzeugt jedoch ein Ergebnis in PowerPivot.

Keine Unterstützung für Zwei-Try-Umwandlungen in DirectQuery
In-Memory-Modelle versuchen häufig eine zweite Umwandlung, wenn die erste fehlschlägt. Dies geschieht niemals im DirectQuery-Modus.

BEISPIEL: TODAY() + "13:14:15"

In diesem Ausdruck weist der erste Parameter den Typ "datetime " auf, und der zweite Parameter hat typ "string". Die Casts beim Kombinieren der Operanden werden jedoch unterschiedlich behandelt. DAX führt eine implizite Umwandlung von String in Double durch. In Speichermodellen versucht das Formelmodul, direkt in double zu umwandeln, und wenn dies fehlschlägt, wird versucht, die Zeichenfolge in datetime zu umwandeln.

Im DirectQuery-Modus erfolgt nur die direkte Umwandlung von String in double. Wenn diese Umwandlung fehlschlägt, zeigt die Formel einen Fehler an.

Mathematische Funktionen und arithmetische Vorgänge

Einige mathematische Funktionen geben unterschiedliche Ergebnisse im DirectQuery-Modus aufgrund von Unterschieden im zugrunde liegenden Datentyp oder den Umwandlungen zurück, die in Vorgängen angewendet werden können. Außerdem können sich die oben beschriebenen Einschränkungen für den zulässigen Wertebereich auf das Ergebnis arithmetischer Vorgänge auswirken.

Reihenfolge der Hinzufügung
Wenn Sie eine Formel erstellen, die eine Reihe von Zahlen hinzufügt, verarbeitet ein Speichermodell möglicherweise die Zahlen in einer anderen Reihenfolge als ein DirectQuery-Modell. Wenn Sie also viele sehr große positive Zahlen und sehr große negative Zahlen haben, können Sie möglicherweise einen Fehler in einem Vorgang erhalten, der das Ergebnis eines anderen Vorgangs beeinflusst.

Verwendung der POWER-Funktion
BEISPIEL: POWER(-64, 1/3)

Im DirectQuery-Modus kann die POWER-Funktion keine negativen Werte als Basis verwenden, wenn sie auf einen Bruch exponenten ausgelöst wird. Dies ist das erwartete Verhalten in SQL Server.

In einem Speichermodell gibt die Formel -4 zurück.

Numerische Überlaufvorgänge
In Transact-SQL geben Vorgänge, die zu einem numerischen Überlauf führen, einen Überlauffehler zurück. Daher lösen Formeln, die zu einem Überlauf führen, auch einen Fehler im DirectQuery-Modus aus.

Die gleiche Formel, die in einem Speichermodell verwendet wird, gibt jedoch eine ganze Zahl mit acht Byte zurück. Das liegt daran, dass das Formelmodul keine Überprüfungen auf numerische Überläufe durchführt.

LOG-Funktionen mit Leerzeichen geben unterschiedliche Ergebnisse zurück.
SQL Server behandelt Nullen und Leerzeichen anders als das xVelocity-Modul. Daher gibt die folgende Formel einen Fehler im DirectQuery-Modus zurück, gibt aber unendliche (-inf) im Speichermodus zurück.

EXAMPLE: LOG(blank())

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

Weitere Informationen zum leeren Datentyp in DAX finden Sie in der DAX-Syntaxreferenz.

Division durch 0 und Division durch Leer
Im DirectQuery-Modus führt division by zero (0) oder division by BLANK immer zu einem Fehler. SQL Server unterstützt nicht die Vorstellung von Unendlichkeit, und da das natürliche Ergebnis einer Division um 0 unendlich ist, ist das Ergebnis ein Fehler. SQL Server unterstützt jedoch die Division durch Nullen, und das Ergebnis muss immer gleich Null sein.

Anstatt im DirectQuery-Modus unterschiedliche Ergebnisse für diese Vorgänge zurückzugeben, geben beide Arten von Vorgängen (Division durch Null und Division durch NULL) stattdessen einen Fehler zurück.

Beachten Sie, dass in Excel und in PowerPivot-Modellen auch division by zero einen Fehler zurückgibt. Division durch eine Leerstelle ergibt eine Leerstelle.

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

1/BLANK

1/0

0.0/BLANK

0/0

Der Ausdruck BLANK/BLANK ist ein Sonderfall, der BLANK sowohl für Speichermodelle als auch im DirectQuery-Modus zurückgibt.

Unterstützte numerische und Datums-/Uhrzeitbereiche

Formeln in PowerPivot- und tabellarischen Modellen im Arbeitsspeicher unterliegen den gleichen Einschränkungen wie Excel in Bezug auf maximal zulässige Werte für reelle Zahlen und Datumsangaben. Es können jedoch Unterschiede auftreten, wenn der Maximalwert aus einer Berechnung oder Abfrage zurückgegeben wird oder wenn Werte konvertiert, umgewandelt, gerundet oder abgeschnitten werden.

• Wenn Werte der Typen "Währung " und " Real " multipliziert werden und das Ergebnis größer als der maximal mögliche Wert ist, wird im DirectQuery-Modus kein Fehler ausgelöst, und es wird ein Nullwert zurückgegeben.

• In Speichermodellen wird kein Fehler ausgelöst, der Maximalwert wird jedoch zurückgegeben.

Da die zulässigen Datumsbereiche für Excel und SQL Server unterschiedlich sind, können die Ergebnisse garantiert nur übereinstimmen, wenn sich Datumswerte innerhalb des gemeinsamen Datumsbereichs befinden, der einschließlich der folgenden Datumsangaben ist:

• Frühestes Datum: 1. März 1990

• Spätestes Datum: 31. Dezember 9999

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

Gleitkommawerte, die von der CEIL-Funktion unterstützt werden
BEISPIEL: EVALUATE ROW("x", CEILING(-4.398488E+30, 1))

Das Transact-SQL Äquivalent der DAX CEILING-Funktion unterstützt nur Werte mit einer Größe von 10^19 oder weniger. Eine Faustregel besteht darin, dass Gleitkommawerte in bigint passen sollten.

Datepart-Funktionen mit Datumsangaben, die außerhalb des Bereichs liegen
Die Ergebnisse im DirectQuery-Modus werden garantiert mit denen in Speichermodellen übereinstimmen, nur wenn sich das als Argument verwendete Datum im gültigen Datumsbereich befindet. Wenn diese Bedingungen nicht erfüllt sind, wird entweder ein Fehler ausgelöst, oder die Formel gibt unterschiedliche Ergebnisse in DirectQuery zurück als im Speichermodus.

BEISPIEL: MONTH(0) oder YEAR(0)

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

In Speichermodellen geben die Ausdrücke 1 bzw. 1900 zurück.

BEISPIEL: EOMONTH(0.0001, 1)

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

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

Die Ergebnisse dieses Ausdrucks sollten im DirectQuery-Modus und im Speichermodus identisch sein.

Verkürzung von Zeitwerten
BEISPIEL: SECOND(1231.04097222222)

Im DirectQuery-Modus wird das Ergebnis abgeschnitten und folgt den Regeln von SQL Server, und der Ausdruck ergibt 59.

In Speichermodellen werden die Ergebnisse der einzelnen Zwischenvorgänge gerundet; Daher wird der Ausdruck auf 0 ausgewertet.

Das folgende Beispiel zeigt, wie dieser Wert berechnet wird:

1. Der Anteil der Eingabe (0,04097222222) wird mit 24 multipliziert.

2. Der resultierende Stundenwert (0,9833333328) wird mit 60 multipliziert.

3. Der resultierende Minutenwert ist 58,999999968.

4. Der Bruchteil des Minutenwerts (0,9999999968) wird mit 60 multipliziert.

5. Der resultierende zweite Wert (59,999999808) wird auf 60 gerundet.

6. 60 entspricht 0.

SQL-Zeit-Datentyp nicht unterstützt
In-Memory-Modelle unterstützen die Verwendung des neuen SQL-Zeitdatentyps nicht. Im DirectQuery-Modus geben Formeln, die auf Spalten mit diesem Datentyp verweisen, einen Fehler zurück. Zeitdatenspalten können nicht in ein Speichermodell importiert werden.

In PowerPivot und in zwischengespeicherten Modellen wandelt das Modul manchmal den Zeitwert in einen akzeptablen Datentyp um, und die Formel gibt ein Ergebnis zurück.

Dieses Verhalten wirkt sich auf alle Funktionen aus, die eine Datumsspalte als Parameter verwenden.

Währung

Wenn im DirectQuery-Modus das Ergebnis eines arithmetischen Vorgangs den Typ "Währung" aufweist, muss der Wert innerhalb des folgenden Bereichs liegen:

• Minimum: -922337203685477,5808

• Maximal: 922337203685477,5807

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

Wenn Währungs - und Real-Typen multipliziert werden und das Ergebnis größer als 9223372036854774784 (0x7ffffffffffffc00) ist, löst der DirectQuery-Modus keinen Fehler aus.

In einem Speichermodell wird ein Fehler ausgelöst, wenn der absolute Wert des Ergebnisses größer als 922337203685477,4784 ist.

Der Vorgang führt zu einem Wert außerhalb des zulässigen Bereichs.
BEISPIEL: Currency sample 2

Wenn Vorgänge mit zwei Währungswerten zu einem Wert führen, der sich außerhalb des angegebenen Bereichs befindet, wird ein Fehler in Speichermodellen ausgelöst, aber nicht in DirectQuery-Modellen.

Kombinieren von Währungen mit anderen Datentypen
Die Aufteilung von Währungswerten nach Werten anderer numerischer Typen kann zu unterschiedlichen Ergebnissen führen.

Aggregationsfunktionen

Statistische Funktionen in einer Tabelle mit einer Zeile geben unterschiedliche Ergebnisse zurück. Aggregationsfunktionen über leere Tabellen verhalten sich auch in Speichermodellen anders als im DirectQuery-Modus.

Statistische Funktionen über einer Tabelle mit einer einzelnen Zeile
Wenn die Tabelle, die als Argument verwendet wird, im DirectQuery-Modus eine einzelne Zeile enthält, geben statistische Funktionen wie STDEV und VAR null zurück.

In einem Speichermodell gibt eine Formel, die STDEV oder VAR über eine Tabelle mit einer einzelnen Zeile verwendet, eine Division durch Nullfehler zurück.

Textfunktionen

Da relationale Datenspeicher unterschiedliche Textdatentypen bereitstellen als Excel, werden beim Durchsuchen von Zeichenfolgen oder beim Arbeiten mit Teilzeichenfolgen möglicherweise unterschiedliche Ergebnisse angezeigt. Die Länge von Zeichenfolgen kann auch unterschiedlich sein.

Im Allgemeinen können alle Zeichenfolgenmanipulationsfunktionen, die Spalten mit fester Größe verwenden, als Argumente unterschiedliche Ergebnisse aufweisen.

Darüber hinaus unterstützen einige Textfunktionen in SQL Server zusätzliche Argumente, die in Excel nicht bereitgestellt werden. Wenn für die Formel das fehlende Argument erforderlich ist, können Sie unterschiedliche Ergebnisse oder Fehler im Speichermodell erhalten.

Vorgänge, die ein Zeichen mit LINKS, RECHTS usw. zurückgeben, können das richtige Zeichen zurückgeben, aber in einem anderen Fall oder ohne Ergebnisse
BEISPIEL: LEFT(["text"], 2)

Im DirectQuery-Modus ist der Fall des zurückgegebenen Zeichens immer identisch mit dem Buchstaben, der in der Datenbank gespeichert ist. Das xVelocity-Modul verwendet jedoch einen anderen Algorithmus zur Komprimierung und Indizierung von Werten, um die Leistung zu verbessern.

Standardmäßig wird die Latin1_General Sortierung verwendet, bei der die Groß-/Kleinschreibung nicht beachtet wird, die Akzente jedoch berücksichtigt werden. Wenn es daher mehrere Instanzen einer Textzeichenfolge in Kleinbuchstaben, Groß- oder Kleinschreibung gibt, werden alle Instanzen als dieselbe Zeichenfolge betrachtet, und nur die erste Instanz der Zeichenfolge wird im Index gespeichert. Alle Textfunktionen, die mit gespeicherten Zeichenfolgen arbeiten, rufen den angegebenen Teil des indizierten Formulars ab. Daher würde die Beispielformel denselben Wert für die gesamte Spalte zurückgeben, wobei die erste Instanz als Eingabe verwendet wird.

Zeichenfolgenspeicher und Sortierung in tabellarischen Modellen

Dieses Verhalten gilt auch für andere Textfunktionen, einschließlich RECHTS, TEIL usw.

Zeichenfolgenlänge wirkt sich auf Ergebnisse aus
BEISPIEL: SEARCH("within string", "sample target text", 1, 1)

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

In einem In-Memory-Modell wird die Zeichenfolge, die durchsucht wurde, zurückgegeben, wobei ihre Länge jedoch auf die Länge des <Texts> abgeschnitten ist.

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

Wenn die Länge der Ersetzungszeichenfolge größer als die Länge der ursprünglichen Zeichenfolge ist, gibt die Formel im DirectQuery-Modus NULL zurück.

In Speichermodellen folgt die Formel dem Verhalten von Excel, das die Quellzeichenfolge und die Ersetzungszeichenfolge verkettet, die CACalifornia zurückgibt.

Implizites TRIM 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>)). Daher werden nur führende und nachfolgende Leerzeichen entfernt.

Im Gegensatz dazu entfernt die gleiche Formel in einem Speichermodell Leerzeichen innerhalb der Zeichenfolge nach dem Verhalten von Excel.

Implizites RTRIM mit Verwendung der LEN-Funktion
BEISPIEL: LEN('string_column')

Wie SQL Server entfernt der DirectQuery-Modus automatisch Leerzeichen vom Ende der Zeichenfolgenspalten: d. h. er führt einen impliziten RTRIM aus. Daher können Formeln, die die LEN-Funktion verwenden, unterschiedliche Werte zurückgeben, wenn die Zeichenfolge nachfolgende Leerzeichen enthält.

In-Memory 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 drei (3) Parameter enthält: einen Verweis auf eine Spalte, den alten Text und den neuen Text. Wenn Sie die zweite Formel verwenden, wird ein Fehler ausgelöst.

In Speichermodellen können Sie einen optionalen vierten Parameter verwenden, um die Instanznummer der zu ersetzenden Zeichenfolge anzugeben. Sie können z. B. nur die zweite Instanz usw. ersetzen.

Einschränkungen für Zeichenfolgenlängen für REPT-Vorgänge
In Speichermodellen muss die Länge einer Zeichenfolge, die sich aus einem Vorgang mit REPT ergibt, kleiner als 32.767 Zeichen sein.

Diese Einschränkung gilt nicht im DirectQuery-Modus.

Teilzeichenfolgenvorgänge geben je nach Zeichentyp unterschiedliche Ergebnisse zurück.
BEISPIEL: MID([col], 2, 5)

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

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

In einem Speichermodell wird das Ergebnis am letzten Zeichenfolgenzeichen ohne Auffüllung beendet.

Im DirectQuery-Modus unterstützte Funktionen

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

Textfunktionen.

KONKATENIEREN

FINDEN

LINKS

LEN

MITTE

ERSETZEN

WIEDERHOLEN

Richtig

ERSATZ

TRIMMEN

Statistische Funktionen

ZÄHLEN

STDEV. P

STDEV. S

STDEVX. P

STDEVX. S

VAR.P

VAR. S

VARX. P

VARX. S

Datums-/Uhrzeitfunktionen

Datum

EDATE

EOMONTH

Datum

ZEIT

SEKUNDE

Mathematische und Zahlenfunktionen

DECKE

LN

Protokoll

LOG10

Energie

DAX-Tabellenabfragen

Es gibt einige Einschränkungen beim Auswerten von Formeln für ein DirectQuery-Modell mithilfe von DAX-Tabellenabfragen. DirectQuery unterstützt nicht das Verweisen auf dieselbe Spalte zweimal in einer ORDER BY-Klausel. Die entsprechende Transact-SQL Anweisung kann nicht erstellt werden, und die Abfrage schlägt fehl.

In einem Speichermodell hat die Wiederholung der ORDER by-Klausel keine Auswirkungen auf die Ergebnisse.

Funktionen werden im DirectQuery-Modus nicht unterstützt

Einige DAX-Funktionen werden in Modellen, die im DirectQuery-Modus bereitgestellt werden, nicht unterstützt. Die Gründe, aus denen eine bestimmte Funktion nicht unterstützt wird, können eine beliebige Kombination dieser Gründe enthalten:

• Das zugrunde liegende relationale Modul kann keine Berechnungen ausführen, die denen entsprechen, die vom xVelocity-Modul ausgeführt werden.

• Die Formel kann nicht in einen entsprechenden SQL-Ausdruck konvertiert werden.

• Die Leistung des konvertierten Ausdrucks und der resultierenden Berechnungen wäre inakzeptabel.

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

Pfadfunktionen

PFAD

PATHCONTAINS

PATHITEM

PATHITEMREVERSE

Weglänge

Sonstige Funktionen

ZÄHLENBLANK

FEST

FORMAT

RAND

RANDBETWEEN

Zeitintelligenzfunktionen: Anfangs- und Enddaten

DATESQTD

DATUMSANGABEN

DATESMTD

DATESQTD

DATESINPERIOD

TOTALMTD

TOTALQTD

TOTALYTD

DATEN_IN_ZEITRAUM

GLEICHER ZEITRAUM IM VORJAHR

PARALLELPERIOD

Zeitintelligenzfunktionen: Bilanzen

ERÖFFNUNGSSALDOMONAT

ERÖFFNUNGSSALDOQUARTAL

Eröffnungsbilanzjahr

Endbestand Monat

Quartalsendbilanz

Jahresabschlusssaldo

Zeitintelligenzfunktionen: Vorherige und nächste Zeiträume

VORTAG

VORHERIGERMONAT

vorheriges Quartal

VORHERIGES JAHR

NÄCHSTER TAG

NÄCHSTER MONAT

nächstes Quartal

NEXTYEAR

Zeitintelligenzfunktionen: Zeiträume und Berechnungen über Zeiträume

STARTOFMONTH

STARTOFQUARTER

STARTDESJAHRES

ENDOFMONTH

ENDOFQUARTER

ENDOFYEAR

FIRSTDATE

Letztes Datum

DATEADD

Siehe auch

DirectQuery-Modus (SSAS tabellarisch)