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.

Bei der Arbeit mit Beispieldatenbanken für Data Warehousing, die ja jetzt auf Codeplex zum Download verfügbar sind, wird so mancher sich wundern: Struktur und Daten der Datenbank AdventureWorksDW2008 wurden gegenüber SQL 2005 (und den CTP-Versionen von SQL 2008) leicht verändert! Auf den ersten Blick ist das seltsam, denn die AdventureWorksDW-Datenbank ist im BI-Bereich so eine Art “gemeinsame Sprache”! AdventureWorks-Mitarbeiter wie Rachel Valdez und Ito Shu haben schon fast die Popularität von Maria Anders von “Alfreds Futterkiste” in der Northwind-Beispieldatenbank. Einträge in Newsgroups und Foren haben fast keine Chance, beantwortet zu werden, wenn sich das Problem nicht von jedem auch auf AdventureWorks nachvollziehen lässt.

Aber keine Angst: viel ist auch gar nicht passiert, nur eins fiel mir so stark auf, dass ich die Finger nicht stillhalten konnte und bloggen musste: Die Zeitdimensions-Tabelle. Sie heißt nicht mehr DimTime, sondern DimDate; und ewig predige und predige ich, und endlich ist es bis nach Redmond gedrungen: der Primärschlüssel der Zeitdimension im Data Warehouse soll nicht nur ein per IDENTITY hochgezählter, bedeutungsloser Integer-Wert sein (z.B. “Anzahl Tage seit dem 1.1.2000″), sondern das echte Datum, in einem INTEGER verschlüsselt im Format JJJJMMTT. Das spart Platz, ist lesbar, leicht zu konvertieren, gut zu sortieren etc. pp. Und so ist es jetzt auch in der Beispieldatenbank, danke dafür!

Noch eine lustige Änderung: in DimProduct haben wir jetzt endlich eine GermanDescription, mit so schönen Inhalten wie: “Für echte Waldprofis. Ein extrem robustes Rad, mit dem Sie auf allen Pfaden sicher unterwegs sind”. Leider gibt es aber immer noch keinen GermanProductName!

Letztendlich ist das etwas fragwürdig: Offenbar benutzen immer noch viele DWH-Designer AdventureWorksDW als Entwurfs-Vorlage, mangels bessrer Materialien. Wenn man diese Datenbank dann schon anpackt und ändert, dann hätte man natürlich auch gleich radikal alles nach best practices umgestalten können! Und viele Nutzer bedauern zu Recht: die neuesten Bewegungsdaten sind immer noch aus dem Juni 2004, also vier Jahre vor dem Erscheinen des Produkts! Das macht Beispiel-Berechnungen mit dem “aktuellem Datum” in Berichten oder in Cubes sehr mühevoll.