2013-03-20

Versionsdschungel: PowerPivot und SQL Server

Es bring eine Reihe von Vorteilen, die mit Excel erstellten PowerPivot Modelle und Analysen nach SharePoint hochzuladen und dort bereitzustellen. Die wichtigsten sind:
  • Zentraler Speicherort
  • Zugangsberechtigung mittels SharePoint Berechtigungen
  • Web-basierte Clients
  • zeitgesteuerte Aktualisierung der Daten  
  • überwachte Ausführung: Welche Berichte werden sehr häufig oder gar nicht genutzt?
Nun gibt es verschiedene Versionen des PowerPivot Add-Ins für Excel. Welche Versionen des Add-Ins mit welchen Versionen von SharePoint und SQL Server zusammenpassen, das ist (wie ich gerade feststellen musste) gar nicht so offensichtlich.

Versionen von PowerPivot in Excel

Das kostenfreie PowerPivot Add-In gibt es ausschließlich für Excel 2010. Excel 2013 enthält dieses Add-In bereits als festen Bestandteil. Zwei Versionen dieses Add-Ins sind für den Download verfügbar:
Versionsnr. Bezeichnung
1050 Microsoft SQL Server 2008 R2 PowerPivot for Microsoft Excel 2010
1100 Microsoft SQL Server 2012 SP1 PowerPivot for Microsoft Excel 2010

Dass der Name des Add-Ins so lautet, wie dieVersionen von SQL Server, ist etwas irreführend. Schließlich sind Excel und PowerPivot ja zunächst einmal völlig unabhängig vom SQL Server.

Zusammenspiel von Excel/PowerPivot und SharePoint

Wenn Sie PowerPivot Modelle nach SharePoint hochladen, findet die Verarbeitung der Daten auf einer speziell für die Zusammenarbeit mit SharePoint konfigurierten Instanz von SQL Server Analysis Services (SSAS) statt. Diese SSAS Instanz wird so installiert, dass sie im "tabularen Modus" läuft. Damit die SSAS Instanz das in Excel erstellte PowerPivot Modell auch tatsächlich öffnen und ausführen kann, müssen die SSAS Version und die Version des PowerPivot Add-Ins zueinander passen. Mit diesem Hintergrundwissen erschließt sich auch, warum das PowerPivot Add-In die Version eines SQL Servers in seinem Namen trägt.
Die Zeichnung soll dieses Zusammenspiel verdeutlichen:

Korrelation der Version von PowerPivot mit der Version von SQL Server
Dabei gelten folgende Regeln:
  • Eine PowerPivot Datei, die mit einer älteren Version des Add-Ins erstellt wurde, wird bei der Veröffentlichung auf die neuere Version von SSAS aktualisiert.
  • Eine PowerPivot Datei, die mit einer Version des Add-Ins erstellt wurde, die neuer ist als die SSAS Version, kann nicht veröffentlicht werden.
  • PowerPivot Modelle, die mit Excel 2013 erstellt wurden, können nicht auf SharePoint 2010 veröffentlicht werden.
Es ist also ganz wichtig, dass Sie bei einem Roll-Out von PowerPivot die Clients im Unternehmen mit der zum SQL Server passenden Version von PowerPivot ausstatten!

Weiterführende Links

Nachfolgend die Links, die mir beim Klären dieser Frage geholfen haben. Hier finden Sie auch noch weiter gehende Informationen.

http://msdn.microsoft.com/de-de/library/bb522628(v=SQL.110).aspx
http://office.microsoft.com/en-us/excel-help/version-compatibility-between-powerpivot-data-models-in-excel-2010-and-excel-2013-HA103929426.aspx
http://sqlblog.com/blogs/marco_russo/archive/2013/01/14/powerpivot-compatibility-across-versions.aspx

2013-03-17

SSIS: Cubes als Datenquelle

Mit Integration Services lassen sich Daten aus unterschiedlichsten Quellen zusammenführen - klar. Aber wie sieht es eigentlich mit Daten aus, die aus SSAS Cubes kommen?

Das Problem

Eigentlich sollte es kein Problem geben: Sie erstellen einen OLE DB Connection Manager zu der SSAS Datenbank und verwenden diesen in einer OLE DB Datenquelle. Das sieht zunächst auch gut aus, sieht man von der Warnung ab, die darauf hinweist, dass alle Spalten in den Datentyp DT_WSTR umgewandelt werden.
OLE DB Datenquelle (Analysis Services)

Ein MDX Statement anstelle eines SQL Statements geht auch
Der Button "Preview" liefert (nach einer Warnung wegen der Typumwandlung) auch die Vorschau der Daten wie erwartet. Wenn Sie jedoch den Datenfluss ausführen, dann gibt es einen Laufzeitfehler, dessen Ursache nicht klar im Protokoll zu erkennen ist.

Lösung (1)

Connection Manager haben eine Reihe von Eigenschaften, die man erst dann sieht, wenn man nach einem Doppelklick auf den Connection Manager die Schaltfläche "Data Links" anklickt.
Der Button "Data Links" führt zu den Eigenschaften der Verbindung
Dort wählen Sie den Reiter "Alle", um alle Eigenschaften zu sehen und wählen Sie dann die Eigenschaft "Extended Properties" aus. Geben Sie hier den Text "Format=Tabular" ein, wie auf dem nachfolgenden Bild zu sehen.
Für die Eigenschaft "Extended Properties" muss der Wert "Format=Tabular" eingestellt werden, damit die OLE DB Datenquelle MDX Abfragen fehlerfrei ausführt.
Wenn sie nun den Datenflusstask ausführen, gibt es keinen Laufzeitfehler mehr.
Diesen wertvollen Tipp verdanke ich Sherry Lis Blog.

Lösung (2)

Eine überraschend einfache Alternative ist die Verwendung einer ADO.NET Datenquelle anstelle der OLE DB Datenquelle. Dort tritt der Fehler gar nicht erst auf.