Mittlerweile hat es sich herumgesprochen, dass Microsoft mit dem Visual Studio 2005 auch ein ReportViewer-Control bereitstellt, dass man einfach so in seinen Anwendungen einsetzen kann. Damit kann drei Dinge, eines davon wird von Microsoft aber nicht groß beschrieben…

  • Man kann Berichte ansehen, die in einem Reporting-Service aufbereitet wurden.
    Diese Nutzung beschreibt Microsoft super ausführlich. Immerhin wird der Reporting-Service inzwischen sogar mit der Express-Edition ausgeliefert.
  • Man kann in seinem Projekt einen Bericht erstellen und ihn in seine Anwendung reinkompilieren. Das wird von Microsoft leidlich beschrieben. Man kann damit einen Bericht am erstellen und aufbereiten (mit allen schicken Features der Reporting-Services ohne ihn installieren zu müssen). Leider kann man damit nur genau einen Bericht pro Control ansehen.
  • Außerdem kann man den Control dazu nutzen viele verschiedene Berichte anzuzeigen. Im Prinzip kann man sogar beliebige Berichte anzeigen, wenn man bereit ist, den Aufwand zu erbringen. Damit kann man aus den Reporting-Services das schickste nutzen, die Anzeige und das Rendering der Berichte (inkl. Export nach PDF, Excel usw.), ohne eine Server-Anwendung installieren und konfigurieren zu müssen. Warum das von Microsoft nicht an die große Glocke gehangen wird, ist klar, oder? Sie erwähnen zwar mal die Möglichkeit, aber eine Anleitung fand ich nicht…

Zum letzteren fand ich lediglich einen brauchbaren Artikel, der in Visual-Basic kurz skizziert, wie man das anstellen muss: "Take Control of Your Reports with ReportViewer, Part 2". Er ist kostenpfichtig, die Code-Fragmente sind frei zugänglich. Leider wird darin alles in Visual-Basic gemacht. Es hat eine Weile gedauert bis ich das Prinzip verstanden habe. Ich habe folgende Erkenntnisse gewonnen:

Das ReportViewer-Control übernimmt nur die Anzeige des Berichts: also das Rendering und die Aufbereitung der Daten. Alles andere muss die eigene Anwendung erledigen:

  • Zusammenstellen des SQL-Statements, mit dem die Daten gelesen werden. Die Query kann man eigentlich auch aus dem Bericht rauslesen, wenn man sich nicht scheut, sie aus dem XML-File zu entnehmen.
  • Die Übergabe der im Bericht enthaltenen Parameter. In dem Beispiel wird gezeigt, wie man dem Bericht-Objekt die Parameter entlocken kann.
  • Bereitstellen einer Datasource, die dynamisch erstellt werden kann. Nur der Name muss so sein, wie im Bericht angegeben.

Im ersten Schritt kann man so eine Hülle für das ReportViewer-Control schreiben, die dem Entwickler anhand von bestimmten Namens-Konventionen das Leben leicht macht, z.B. DataSource1 oder Param01.
Andererseits ist die Struktur der Berichte (XML-Datei) sehr einsichtig, deswegen kann man sie auch im ersten Schritt auswerten und die Query, deren Parameter und den Namen der Data-Source ermitteln. Im zweiten Schritt muss man das Control lediglich initialisieren und schon hat man ein Universal-ReportViewer-Control.