SQL Server 2008 R2 SSRS wartet mit einer interessanten Neuerung auf, nämlich der Suche in Datasets. Damit gibt es Möglichkeiten zwei Datasets in einem Datenbereich zu verknüpfen.

Grundsätzlich gilt: Ein Datenbereich in einem Report kann nur an ein Dataset gebunden sein. Es ist also sinnvoll, alle benötigten Felder bereits vom Datenbankserver in ein Dataset vereinigen zu lassen. Es sind aber auch Situationen denkbar, in denen es nicht möglich ist, die benötigten Felder in ein Dataset zu integrieren (z.B. bei der Nutzung von bereits bestehenden Shared Datasets oder bei verschiedenen Quellen). Die Möglichkeiten in einem Datenbereich auf Inhalte eines zweiten Datasets zuzugreifen waren bisher wenig komfortabel. Es gab dazu nur die Funktionen Last, First und die Aggregatfunktionen, die auf das gesamte Ziel-Dataset anzuwenden sind. Ein wahlfreier Zugriff auf eine beliebige Zeile in dem Ziel-Dataset, anhand eines Suchwertes, wurde nicht von SSRS unterstützt. Um das zu erreichen, war es nötig, das komplette Dataset in einem Hashtable zu cachen und dann mittels einer Custom-Code-Funktion den gesuchten Wert zu ermitteln.

Mit der Veröffentlichung von SQL Server 2008 R2 SSRS gibt es dafür jetzt die Lookup-Funktionen. Diese gibt es gleich in drei Versionen: Lookup, LookupSet und MultiLookup.

Die Lookup-Funktion wertet einen Wert (Ausdruck) pro Zeile aus und sucht durch Vergleich mit diesem Wert eine passende Zeile im Ziel-Dataset. LookupSet wertet ebenfalls einen Wert pro Zeile im aktuellen Dataset aus, liefert aber alle passenden Zeilen aus dem Ziel-Dataset. MultiLookup wertet mehrere Werte pro Zeile des aktuellen Datasets aus und liefert alle passenden Zeile aus dem Ziel-Dataset. Konkret wird für jede passende Zeile ein Wert zurückgegeben, der das Ergebnis der Auswertung eines Ausdrucks über die Felder der Zeile ist. Im einfachsten Fall wird der Wert eines der Felder zurückgegeben.

Diese drei Lookup-Funktionen sollen hier demonstriert werden.

Lookup

				

Ein Beispiel für den Einsatz von Lookup:

Der Umsatz pro Mitarbeiter aus Dataset2 soll in der Tabelle  angezeigt werden, die mit Dataset1 verknüpft ist.

Dazu wird ein neues Feld mit einem Ausdruck erstellt. Der hier verwendete Ausdruck lautet: =Lookup(Fields!MitarbeiterID.Value, Fields!PersonalID.Value, Fields!Umsatz.Value, “DataSet2″)

• Der erste Parameter, Fields!MitarbeiterID.Value, ist ein Feld der Tabelle (Datenbereichs), die an Dataset1 gebunden ist. Es ist aber auch möglich einen Ausdruck zu verwenden, um z.B. mehrere Felder zu konkatenieren, wenn der Vergleich mit den Zeilen im Ziel-Dataset mehrere Spalten berücksichtigen soll.
• Der zweite Parameter , Fields!PersonalID.Value , ist ein Feld aus dem Dataset2, in dem nach einer passenden Zeile gesucht werden soll. Es kann auch ein Ausdruck verwendet werden. Wie bei einem Join wird verglichen ob dieser Wert mit dem Suchwert (der erste Parameter) übereinstimmt.
• Der dritte Parameter, Fields!Umsatz.Value , gibt den Rückgabewert der Funktion an. Auch hier kann anstelle eines Feldes ein Ausdruck angegeben werden. Bei Lookup wird der Rückgabewert aus der ersten Zeile ermittelt, bei der die Suche erfolgreich war. Gibt es keine Zeile, die die Bedingung erfüllt, liefert der Lookup-Aufruf Nothing zurück.
• Der vierte Parameter benennt das Ziel-Dataset (hier Dataset2), in dem ein passender Wert gesucht wird.

 
Die mit Dataset1 verbundene Tabelle enthält jetzt die gewünschten Werte aus DataSet2.

LookupSet   Bei der Lookup-Funktion wird wie bereits beschrieben nur die erste Zeile berücksichtigt, auf die der Suchwert passt. LookupSet wertet immer alle Zeilen des Ziel-Datasets aus und liefert für jede passende Zeile einen Wert zurück. LookupSet gibt diese Werte in Form eines Array zurück. Dieses Array kann nicht direkt als Ausgabe eines Textfeldes verwendet werden. Es muss also eine Bearbeitung z.B. mit der VB-Funktion Join erfolgen wodurch aus dem Array ein anzeigefähiger Wert wird. Das Array kann auch als Argument für eine Custom-Code-Funktion verwendet werden, um einen Anzeigewert zu bestimmen.

Beispiel für die Verwendung von LookupSet

=Join(LookupSet(Fields!ProductCategoryID.Value, Fields!ProductCategoryID.Value, Fields!Name.Value, “DataSet2″),”, “)

Zu Jeder Zeile in DataSet1 werden alle passenden Zeilen aus DataSet2 gesucht. Join wandelt das Ergebnis-Array in einen String um, der anschließend im Feld Subcategory zu sehen ist.

Zu Jeder ProductCategory sind nun alle Subcategories in einem Feld zu sehen.

MultiLookup

MulitLookup nimmt keinen einzelnen Wert sondern ein Array von Suchwerten pro Zeile. Ein Aufruf von MultiLookup wird dann so durchgeführt, dass für jedes Element des Suchwerte-Arrays ein gesonderter Lookup-Aufruf durchgeführt wird. Die Ergebnisse der einzelnen Lookup's werden dann dem Ergebnis-Array zugefügt.

Ein Mehrwertiger Parameter kann direkt als Suchwert verwendet werden. Ein String, der eine Liste von Werten enthält, muss erst in ein Array umgewandelt werden. Dazu eignet sich die VB-Funktion Split.

Beispiel: Ein Mehrwertiger Parameter enthält mehrere Monate, die als Auflistung von Zahlwerten angegeben sind. Mithilfe eines Aufrufes der Funktion MultiLookup werden die Zahlwerte in den
jeweiligen Monatsnamen umgewandelt. Dabei wird das Dataset Monatsnamen als Ziel-Dataset für die Suche verwendet.

 
Anzeige der Parameterwerte in einem Textfeld mit dem Ausdruck =Join(Parameters!Monate.Value,”, “)




Anzeige der Werte nach Änderung des Ausdrucks auf =Join(MultiLookup(Parameters!Monate.Value, Fields!MonatNr.Value,Fields!MonatName.Value,”Monatsnamen”),”, “)

Die November CTP des SLQ Server 2008 R2 steht seit einiger Zeit zum Download bereit und bietet zahlreiche neue Features. In diesem Artikel sollen die zahlreichen Neuerungen, die die Reporting Services erhalten haben, beschrieben werden. Wir beschränken uns auf die Features, die unmittelbar mit der Entwicklung der Berichte zu tun haben und lassen die Änderungen, die bezüglich der erweiterten Sharepoint Integration vorhanden sind, außen vor. Der Report Manager hat ein neues Äußeres bekommen und der Report Builder steht jetzt in Version 3.0 zur Verfügung, die auch benötigt wird, um mit den neuen Features arbeiten zu können:

Freigegebene Data Sets

Genau wie freigegebene Datenquellen, die in jedem größerem Projekt verwendet werden, um Änderungen an der Datenquelle an zentraler Stelle zu realisieren, können jetzt auch Data Sets freigegeben werden und in einem geeigneten Ordner auf dem Server zu speichern. Freigegebene Data Sets können von allen Berichten verwendet werden, so können Sie z.B. für einen Parameter, der in mehreren Berichten vorkommt, ein Data Set anpassen, dieses freigeben und es dann auch in den anderen Berichten verwenden.
Mit dem Report Builder können Sie alle freigegebenen Data Sets auf dem Server verwenden, mit dem BIDS hingegen können Sie nur die freigegebenen Data Sets ihres Projekts verwenden.

Report Part Gallery

Seit der November CTP ist es möglich Teile eines Berichts zu veröffentlichen. Diese Report Parts können dann in anderen Berichten verwendet werden. Im Gegensatz zu den freigegebenen Data Sets, können Report Parts in einem neuen Bericht weiter angepasst werden, ohne dass die Vorlage davon beeinflusst wird. Ein Report Part wird sozusagen ein normales Berichtselement im neuen Report. Falls das Original aktualisiert wurde, wird Ihnen dies mitgeteilt, damit Sie Ihre verwendeten Elemente aktualisieren können.
Beim Hinzufügen eines Report Parts werden automatisch die zugehörigen Data Sets und Datenquellen mit angelegt.
Report Parts können sowohl mit dem BIDS, als auch mit dem Report Builder erstellt werden. Sie können aber zurzeit nur mit dem Report Builder verwendet werden, indem Sie einfach per Drag&Drop aus der Report Part Gallery in den Bericht gezogen werden.

Folgende Elemente stehen zur Verfügung:

• Charts
• Tabellen, Matrizen und Listen
• Messgeräte
• Maps
• Bilder
• Rectangles

Neue Berichtselemente zur Datenvisualisierung

Die neuen Berichtselemente sind speziell konzipiert worden, um in Tabellen und Matrizen eingesetzt zu werden.

Sparklines und Data Bars

Sparklines und Data Bars sind einfache Charts, die nur die wesentlichen Elemente beinhalten und gänzlich auf Legenden, Achsen und Beschriftungen verzichten. Sie werden in erster Linie in Tabellen und Matrizen verwendet, um viel Information auf möglichst geringem Raum zu repräsentieren.
Typischerweise zeigen Data Bars nur einen Wert pro Zeile an, um den Vergleich der Werte untereinander zu vereinfachen:

Im Gegensatz zu den Sparklines, die normalerweise den zeitlichen Verlauf wiederspiegeln:

Bei den Sparklines wäre noch anzumerken, dass sie nur in Gruppen- und nicht in Detailzeilen verwendet werden können.

Indikatoren

Indikatoren werden verwendet, um den Status eines Wertes auf den ersten Blick erkennen zu können. Sie werden häufig in Tabellen und Matrizen eingesetzt. Ein Indikator ist ein vereinfachtes Messgerät und kann auch in eben dieses umgewandelt werden. Sie können Trends anhand von Pfeilen, Abstimmungen durch Sterne und Status durch Bilder wie z.B. der Ampel darstellen:

Erweiterungen der RDL Ausdruckssprache

Aggregationen von Aggregationen

In der aktuellen Version ist es endlich möglich Ausdrücke zu verwenden, die Aggregationen von Aggregationen bilden. Dadurch können Werte, wie z.B. der Durchschnitt der monatlichen Einnahmen gebildet werden.
=Avg(Sum(Fields!Reseller_Sales_Amount.Value, “Month”),”Year”)

OverallPageNumber und OverallTotalPages

Zeigt die Gesamtseitenzahl und die aktuelle Seitenzahl bezogen auf das gesamte Dokument. Im Gegensatz zu den schon bekannten Feldern PageNumber und TotalPages, die die Seitenzahlen abhängig von einer Sequenz angeben(die Seitenzahlen können durch ein PageBreak zurückgesetzt werden). Diese Eigenschaften können nur im Seitenkopf oder –fuß verwendet werden.

RenderFormat

Eine weitere neue, in meinen Augen sehr nützliche Eigenschaft, ist die Globale RenderFormat. Zum Einen kann der Name durch Globals!RenderFormat.Name ermittelt werden und zum Anderen, mit der Expression =Globals!RenderFormat.IsInteractive, ob es sich um ein interaktives Ausgabeformat handelt.

Durch die Möglichkeit das Ausgabeformat zu ermitteln ergeben sich ganz neue Gestaltungsmöglichkeiten. So können für ein Excel-Export z.B. Spalten einer Tabelle ein- oder ausgeblendet werden. Es können Abhängig vom Ausgabeformat komplett unterschiedliche Elemente angezeigt werden.
Bei nicht interaktiven Formaten können, durch den Drilldown versteckte Elemente, sichtbar gemacht werden.

PageName

Endlich können Excelsheets einer Excel-Datei mit Namen versehen werden. Dafür müssen Sie einfach den PageName angeben. Wenn Sie den PageName dynamisch vergeben und den Gruppennamen verwenden für den ein PageBreak existiert, bekommt jedes Excelsheet den Namen der Gruppe.

Mit der Eigenschaft PageBreak/Disabled kann z.B., abhängig vom RenderFormat, der Seitenumbruch deaktiviert werden.

Maps

Was man in früheren Versionen der Reporting Services von Drittanbietern kaufen musste, wurde in der aktuellen Version integriert. Dieses neue Berichtselement dient zur Visualisierung von Daten abhängig von ihrer geographischen Lage. Es stehen eine Vielzahl von Karten in der Kartengalerie zur Verfügung (zurzeit, wohl aus rechtlichen Gründen, nur Karten der USA). Falls Sie eine andere Karte benötigen, können auch ESRI-Shapefiles oder SQL Spatial Datentypen verwendet werden. Sie können hinter Ihre Karte noch eine Bing Karte legen, um die Darstellung noch etwas aufzuwerten. Folgende Kartenvisualisierungen stehen zur Verfügung:

• Basic Map (Basis Karte) – Es werden einfach nur Gebiete angezeigt. So können z.B. Ihre Verkaufsgebiete angezeigt werden.
• Color Analytical Map (Farbanalytische Karte) – Informationen werden durch Farbvariationen hervorgehoben. Z.B. werden die Verkaufszahlen pro Gebiet farblich gekennzeichnet.
• Bubble Map (Blasen Karte) – Informationen werden durch die Größe der Blasen angezeigt. Die Blasen liegen zentriert in den zugehörigen Gebieten.

Report Viewer

Der neue Report Viewer verwendet AJAX für die Seitennavigation und die Interaktivität. So wird beim Öffnen eines Drilldowns die aktuelle Scrollposition beibehalten.
Das Aussehen wurde angepasst und optimiert, um mehr Platz für den Bericht zu haben.

Wir konnten natürlich nur einen kurzen Überblick über die neuen Features der Reporting Services des SQL Server 2008 R2 geben und werden daher in den nächsten Blogeinträgen gezielt und detailliert einzelne der oben genannten Features beschreiben.

Herr G. Ordnet, Controller der Firma Adventure Works, möchte sich für ausgewählte Produkte seines Unternehmens die Internetverkäufe und die Frachtkosten ansehen. Er beauftragt den Reportbauer Z. Schnell mit dem Erstellen eines Berichts. Selbiger überdenkt die Anforderung und stellt einen Bericht mit einer Parameterliste aller Produkte zur Verfügung.

Nachdem Herr G. Ordnet mehrere Male alle 606 Produkte seiner Firma in der Auswahlkombobox des Berichtes durchforstet hat, platzt ihm der Kragen und er bittet um eine “vernünftige Einschränkung der Produkte nach Kategorien.”

Ein Glück, dass in der Datenbank diese Produktkategorien vorhanden sind, denkt sich Herr Schnell und entwickelt die sog. “cascading parameters” – also voneinander abhängige, hierarchisch angeordnete Parameter, deren Auswahl die Wertanzahl folgender Parameter einschränkt.

Zuerst werden im Report drei statt einem Parameter erzeugt. Alle Parameter sind mehrwertig und haben keinen Standardwert.

Dann werden drei Datasets für die Parameter mit folgenden Statements angelegt:

Produktkategorie:

SELECT      ProductCategoryKey, EnglishProductCategoryName FROM  DimProductCategory

Produktunterkategorie:

SELECT        ProductSubcategoryKey, EnglishProductSubcategoryName FROM         DimProductSubcategory

WHERE        (ProductCategoryKey IN (@ProductCategory))

Produkte selbst:

SELECT        EnglishProductName, ProductKey FROM  DimProduct

WHERE        (ProductSubcategoryKey IN (@ProdSubCategory))

Schlussendlich erzeugt Herr Schnell ein Dataset für die Werteabfrage:

SELECT   DimProduct.EnglishProductName, FactInternetSales.OrderQuantity * FactInternetSales.UnitPrice AS OrderVolume, FactInternetSales.Freight FROM DimProduct INNER JOIN FactInternetSales ON DimProduct.ProductKey = FactInternetSales.ProductKey

WHERE  (FactInternetSales.ProductKey IN (@Products))


Weil Herr Schnell auf Standardwerte verzichtet hat, und alle vom vorhergehenden Parameter abhängigen Parameterabfragen ohne eine Auswahl des vorhergehenden Parameters nicht getätigt werden können, sind die Auswahlboxen der nachfolgenden Parameter solange deaktiviert, bis die nötige Vorauswahl von Kategorien oder Unterkategorien abgeschlossen ist.

Nun hat Herr G. Ordnet nur die Produkte zur Auswahl, deren Anzahl er vorher durch die Auswahl an Kategorien eingeschränkt hat – und Herr Schnell noch seinen Job.

Eine der häufigsten Anforderungen in Berichten, neben der grafischen Darstellung von Datenreihen, ist die Auflistung von Daten in Tabellen und Matrizen. Dabei sollen in den meisten Fällen auch die Summen der Gruppen und die Gesamtsumme, wie in der ersten Abbildung, gebildet werden.

Ja und, kann doch jeder: Einfach die Sum-Funktion verwenden:

Stimmt, in den meisten Fällen kommen wir damit zum Ziel.

Was aber, wenn wir noch mehr Informationen anzeigen wollen und dadurch einige Werte doppelt vor kommen, wie z.B. in unserem Beispiel, wenn wir nicht nur die Informationen des Internetverkaufs anzeigen wollen, sondern auch noch die Daten der Wiederverkäufer und zwar landesbezogen. Wenn wir dann die Sum-Funktion verwenden bekommen wir folgende Tabelle:

Wie man erkennen kann sind die Informationen über den Internetverkauf unabhängig vom Land, wodurch in jeder Zeile die Gesamtmenge für diesen einen Reiniger angezeigt wird. Der Wert für die Anzahl, der mit der einfachen Summenfunktion ermittelt wurde, summiert natürlich jede Zeile auf, wodurch wir ein Ergebnis von 6 * 908 = 5448 erhalten. Richtig wäre, wenn auch in der Gruppenzeile 908 stehen würde.

Die Lösung

Wir müssen also in der Summenfunktion prüfen, ob der Wert schon mal aufsummiert wurde. Das können wir erreichen, indem wir im Code eine globale Variable vom Typ String definieren. Jedes neue Produkt wird ans Ende des Strings geschrieben, so dass eine Liste mit den einzelnen Produkten entsteht. Als nächstes wird noch eine Funktion benötigt, die zum Einen den Wert und zum Anderen den Produktnamen übergeben bekommt. Diese überprüft, ob das Produkt schon in der Liste steht, falls dies nicht der Fall ist, wird der Wert zurückgegeben und der Name in der Liste aufgenommen. Falls der Name schon vorhanden ist, wird 0 zurückgegeben, wie der Codeausschnitt zeigt:

private productList as String = String.Empty

function DistinctSum(quantity as Integer, product as String) as Integer
    if productList.IndexOf(product) = -1 then
        productList += product + “, ”
        return quantity
    else
        return 0
    end if
end function

Man muss nur darauf achten, dass die Funktion immer Daten vom gleichen Typ zurück gibt, da es sonst passieren kann, dass die Summe nicht berechnet wird.

Abschließend muss die Gruppenzeile so angepasst werden, dass sie die neu erstellte Funktion verwendet. Leider ist es nicht möglich, einfach das Array mit den Details zu übergeben und die Summe zu berechnen. Daher verwenden wir weiterhin die Summenfunktion, um die Liste der Details einer Gruppe zu durchlaufen. Der Trick ist jetzt  nicht einfach ein Feld eines Datasets einzutragen, sondern inerhalb der Summe die im Code erstellte Funktion zu verwenden, die dann für jedes einzelne Element prüft, ob es schon aufaddiert wurde:

=Sum(code.DistinctSum(Fields!Internet_Order_Quantity.Value,Fields!Product.Value))

Wenn der Bericht, wie beschrieben angepasst wurde sollte jetzt für die Anzahl der Bestellungen, wie in der abschließenden Grafik,  der richtige Wert angezeigt werden.

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.

Eine Migration von Berichten mit Dundas Charts von Reporting Services (RS) 2005 nach 2008 funktioniert dank der neu integrierten Diagrammfunktionalitäten in RS 2008 relativ problemlos.

Einige Konvertierungen mit Diagrammen von Dundas laufen allerdings darauf hinaus, dass sie in RS 2008 als fehlerhaft gemeldet werden und auch nicht ersichtlich ist, woran es liegt. Visual Studio bietet an, den Code zu sichten, aber wer möchte gerne seitenlanges XML durchforsten auf der Suche nach möglichen Fehlern?

Empirisch gelangten wir zu dem Schluss, dass in jedem letztlich fehlerhaften Bericht die Dundas Charts in einer Tabelle eingebettet waren. Nun ist die Lösung ganz einfach: in RS 2005 die Charts aus der Tabelle herausschneiden und im Bericht außerhalb der Tabelle einfügen. Der Bericht muss gespeichert und als nächstes in Visual Studio 2008 erneut geöffnet werden. Dieses Mal war die Konvertierung erfolgreich! Der Entwickler braucht nur noch die Charts wieder in die Tabelle an die ursprüngliche Stelle einfügen und umgeht damit einen zeitaufwendigen Neubau.

Vor einer Konvertierung mit Dundas Charts in einer Tabelle die Diagramme also aus der Tabelle herausnehmen und alles wird gut.