English Deutsch

 

Aktuelle Probleme mit dem Abfrage-Designer für MDX

Bei ixto sind wir meistens sehr mit der Produktqualität von Microsoft zufrieden und auch SQL Server 2008 macht auf den ersten Blick einen ausgezeichneten Eindruck. Wir, das Team der Berichtsdesigner, sahen uns allerdings schnell an unsere Toleranzgrenzen gebracht als wir den neuen Abfrage-Designer für MDX im Berichtsdesigner erleben durften.

Nun, nicht jeder von uns schreibt sein MDX selbst, sondern benutzt den sehr komfortablen grafischen Editor. Performance spielt bei vielen Abfragen und natürlich für den Benutzer eine Rolle, also tunen wir gelegentlich die generierten Abfragen manuell, d.h. wir greifen direkt in die MDX-Syntax ein und verändern diese. Manchmal ist eine Modifizierung grundsätzlich notwendig, wenn man beispielsweise in einer Hierarchie nur bis zu einer bestimmten Ebene Daten abfragen möchte.

Wir haben folgende Problemstellen mit dem MDX Abfrage-Designer identifiziert und Microsoft dazu befragt:
 
Verlorene Formatierungen

Modifizierte und formatierte MDX-Abfragen verlieren jegliche Formatierungen, wie z.B. Zeilenumbrüche und Einrückungen, nachdem man den Bericht komplett geschlossen und dann bis zur Abfrage wieder geöffnet hat. Jeder, der sich schon mal die Abfrage eines vom Visual Studio 2005 generierten Parameters angesehen hat, weiß, wie unlesbar dieser Code ist.

 

Die Zeilenumbrüche finden sich allerdings im RDL direkt wieder. Nur ist diese Tatsache wenig hilfreich, wenn die Zeilenumbrüche im Abfrage-Designer nicht angezeigt werden.
Der Bug scheint bisher keine Beachtung bei den Entwicklern gefunden zu haben.
 
Kein Syntax Highlighting

Schon schlimm genug, dass die Formatierung immer verloren geht, da wurde das Syntax Highlighting auch noch Opfer von Integrationsproblemen. Wie im Screenshot zu sehen, ist die Abfrage im neuen Editor so gut wie unlesbar.

 

Es heißt, dass es ein Visual Studio Integrationsproblem war, welches bis zum Release von SQL Server 2008 nicht behoben werden konnte. Es wird angestrebt, es in einer zukünftigen Version zu beheben.

 

Sonderzeichen

In der englischen Version ist das Problem mit den Formatierungen noch gravierender. Hier entstehen Sonderzeichen, die die Zeilenumbrüche sein sollen, aber nicht entsprechend angezeigt werden.

 

Auch dieser Bug scheint bei den Entwicklern noch nicht wirklich angekommen zu sein.

 

Für die Punkte 1 bis 3 gibt es den Workaround, die MDX-Abfrage in eine Abfrage im Management Studio zu kopieren. Hier hat man die Formatierung und das Syntaxhighlighting wieder. Durch zurückkopieren erhält man jetzt auch im Designer die Formatierung zurück.
Leider kann das Management Studio nicht mit den Parametern in der Abfrage umgehen, daher würden wir das MDX Studio von Mosha Pasumansky empfehlen, denn mit dieser Anwendung gewinnen Sie nicht nur das Syntax Highlighting zurück und haben eine Autoformatierungsfunktion, sondern es ist auch möglich Parameter via XML-Tags in die Abfrage einzubinden.
Das MDX Studio ist auf der Seite http://www.mdxstudio.com/ zu finden.
Um sich das Schreiben der einzelnen XML-Tags für die Parameter, es können ja doch manchmal ganz schön viele sein, zu ersparen, kann die Abfrage mit dem SQL-Profiler “mitgeschnitten” und dann direkt in das MDX Studio kopiert werden.

Automatisch überschriebene Parameterdatasets

Die Probleme, die bis jetzt beschrieben wurden, hatten nur etwas mit der Benutzerfreundlichkeit zu tun, das jetzt beschriebene Verhalten kann aber zu richtigen Fehlern führen, wie es unbemerkt bleibt.

Wie auch bei SSRS 2005 werden Datasets für Parameter automatisch generiert, wenn sie in der Hauptabfrage erzeugt werden. Das Problem entsteht, wenn man die Abfrage für die Parameter anpasst, da man vielleicht einige Elemente nicht benötigt, und danach noch mal die Hauptabfrage ändert, wird wieder das “Default” Dataset für den Parameter erstellt und die eigenen Anpassungen gehen verloren.

Was möglicherweise gut gemeint ist, und das manuelle generieren von Parameterdatasets abnehmen soll, führt unter diesen Umständen zu mehrfachem Wiederholen derselben Arbeit oder sogar zu Fehlern, wenn die automatische Änderung unbemerkt bleibt.

Dieses Problem haben die Entwickler wohlwollend aufgenommen und scheint zur Diskussion zu stehen.

 

Ein Workaround das automatische Überschreiben der Parameterdatasets zu unterbinden ist, die Bindungen an die Dimensionen zu entfernen. Als Standardwerte muss man Elemente in MDX-Syntax setzen, was natürlich die Funktionalität des Assistenten einschränkt und das Ändern der Standardwerte stark erschwert.

 

Mit den hier beschriebenen Workarounds ist es aber auch für MDX-Fans durchaus sinnvoll mit dem SSRS 08 zu arbeiten und die neuen Features, wie Tablix und erweiterte Gruppierbarkeit zu nutzen.

Dynamische Rahmen innerhalb einer Matrix und/oder die Knechtschaft des Layouts durch das Dataset

1. Die Anforderung ist simpel:

“Die Linien innerhalb der Matrix sollen Grau und die untere Zeile soll bitte schwarz sein.”

Die meisten Reportdesigner schreiben sich solch ein Anliegen gar nicht auf, sondern setzen schlicht die Rahmenfarbe der Zeilen auf Grau und die des Subtotals auf Schwarz und reichen den Report zufrieden weiter.

Ergebnis:

2. Die Anforderung erweitert sich “gering”:

“Sehr geehrter Reportdesigner, die senkrechten Linien gefallen uns nicht, könnten Sie stattdessen einen Abstand zwischen die Länderspalten einbauen?”

Noch kommt keine Unruhe auf, flugs wird folgendes Design umgesetzt:
Auf den Zeilen wird eine neue Gruppe mit derselben Gruppierung wie die vorhergehende und im Detailfeld der Matrix einfach eine weitere Spalte eingefügt.
Die Rahmen der eingefügten Abstandsspalten bleiben unsichtbar, die Rahmenfarbe des Subtotals bleibt weiterhin schwarz.

Ergebnis:

Die Linie des Subtotals zieht sich leider über alle Spalten hinweg. Dies mag dem einen oder anderen nicht der Rede wert erscheinen, ärgerlich und unschön bleibt es trotzdem.

Konsequenz des pfiffigen Reportdesigners:

Ausblenden der Rahmen des Subtotals und Formatierung der Rahmenfarbe der Zeilengruppen und des Detailfeldes!

Dies kann durch folgende Ausdrücke erreicht werden (bei BorderStyle, Bottom=Solid)

Für die Zeilengruppen (Textbox Product) gilt:
BorderColor=IIF(RowNumber(“MyDataSetName”)=CountRows(“MyDataSetName”), “Black”,”Silver”)
d.h.:
Wenn die letzte Zeile des Datasets erreicht ist, färbe die Rahmen bitte Schwarz ein, sonst Silber.

Für die Zeile funktioniert das prima, für das Detailfeld muss aber auf die letzte Zeile der Spaltengruppe verwiesen werden, da das Scope (“MyDataSetName”) auf Detailebene nicht gültig ist.

Für das Detailfeld (Textbox mit Wertfeld) muss also gelten:
BorderColor=IIF(RowNumber(“MyColumnGroupName“)=CountRows(“MyColumnGroupName “),”Black”,”Silver”)

Und genau an dieser Stelle fängt der Ärger an.

Nehmen wir an, der Reportdesigner ist ein sparsamer Mensch und möchte sich im Dataset die leeren Zeilen für den OrderCount in Australien und Frankreich sparen und filtert diese Zeilen heraus.

MDX:

SELECT
NON
EMPTY

{

[Measures].[Reseller Order Count]

} ON
COLUMNS,

NON
EMPTY
— > !! FILTERT LEERZEILEN

{ (STRTOSET(@countryCountry,CONSTRAINED) ,


STRTOSET(@productProduct,CONSTRAINED))} ON
ROWS
FROM [Adventure Works]

Das Dataset sieht dann wie folgt aus:

Ergebnis im bereitgestellten Report: (Die Vorschau im VisualStudio zählt natürlich NICHT!)

Das Problem wird schnell klar, natürlich ist die letzte Zeile in der Ländergruppe für Australien auch die einzige,
der o.g. Ausdruck sorgt für eine schwarze Färbung und alle
nachfolgenden, vom Report zu rendernden Elemente übernehmen die Formatierung des letzten Elementes, welches noch einen direkten Bezug zur Datasetzeile bzw. den Zeilen der angegebenen Gruppe besitzt. Das Phänomen kann sowohl auf Zeilen wie auch auf Spaltengruppen beobachtet werden.

Ein weiterer Versuch, die Ausdrücke für die Rahmenfarbe anders zu formulieren:
BorderColor=IIF(InScope(“matrix1_RowGroup1″),”Silver”,”Black”)

zeigte gar kein Ergebnis für die Spalten:

Damit bleibt leider kein anderer Schluss, als die Leerzeilen für die Ländergruppierung mit ins Dataset aufzunehmen:

SELECT
NON
EMPTY

{

[Measures].[Reseller Order Count]

} ON
COLUMNS,

–non empty auskommentiert

{ (STRTOSET(@countryCountry,CONSTRAINED) ,


STRTOSET(@productProduct,CONSTRAINED))} ON
ROWS
FROM [Adventure Works]

Dataset:

Gewünschtes Ergebnis im Report: