reporting

Microsoft Reporting Services (SSRS) kann bekanntlich auf diverse unterschiedlichste Arten von Datenquelle zugreifen, so auch auf XML Daten. Dabei muss es nicht zwingend eine fixe XML Datei sein, die auf einem Web Server gehostet ist. Es darf auch das dynamische Ergebnis eines SOAP oder Web API Request’s sein.

Freie Web APIs, die auch brauch- & verwertbare Daten liefern, gibt es einige. Für einen ersten Test habe ich mich im Bereich Wetter & deren Vorhersage umgesehen. Es gibt eine Google Weather API, die allerdings undokumentiert ist und es gibt auch keine Garantie zur Verfügbarkeit bzw. wie lange es diese API noch gibt. Die API liefert ein einfach gehaltenes XML Ergebnis, das man problemlos im Internet Explorer oder Tools wie XML Notepad anzeigen kann. Nur SSRS mag das Ergebnis nicht, es sein ein ungültiges Zeichen in den Daten enthalten; es ist das Zeichen mit Hex-Wert A0 = No-Break Space (geschütztes Leerzeichen) zwischen dem Luftfeuchtewert und dem Prozentzeichen.

Aber es gibt noch andere Wetter APIs und eine frei nutzbare (sofern man sich an die Bedingungen hält) ist die Yahoo Weather API. Die API liefert einen RSS Feed, was aber auch nichts anderes als XML Daten sind, ein Beispiel kann man bei Yahoo sehen. Die Basis URL lautet http://weather.yahooapis.com/forecastrss und es gibt nur zwei Parameter:

   U = Einheit (unit) für die Temperatur Wert
   W = WOEID, die Id der Stadt / Bereich, für den das Wetter abgefragt werden soll.

Die WOEID kann man z.B. über den GeoPlanet-Explorer heraus suchen. Beispiel für Hannover (w=657169) in Grad Celsius (=c):

http://weather.yahooapis.com/forecastrss?u=c&w=657169

Wie kann ich nun das Ergebnis für einen SSRS Report nutzen? Zunächst legt man eine Datenquelle an, da auf die API nur im dem Bericht zugegriffen wird, reicht eine eingebettete Datenquelle, eine freigegeben wird nicht nötig sein; als Verbindungstyp wählt man natürlich XML. In der Verbindungszeichenfolge gibt man nur die URL wie oben an, sonst nichts; die WOEID als dynamischer Parameter gestalte ich später noch. In den „Anmeldeinformationen“ muss „Aktuellen Windows-Benutzer verwenden“ ausgewählt sein; SSRS erwartet immer eine Anmeldeinformation, auch wenn sie nicht benötigt wird.

Als nächstes benötigt man ein Dataset für die anzuzeigenden Daten. Zum Abfragen von XML Daten werden XML Queries verwendet; das war für mich zunächst auch noch etwas neu, auch wenn ich in T-SQL schon ein wenig damit gearbeitet habe; etwas ins Thema eingearbeitet (siehe weiterführende Links unten) und etwas experimentiert, schon habe ich brauchbare Ergebnisse erhalten. Hier mal ein Beispiel, um die Forecast abzufragen, je API Request gibt es für die nächsten zwei Tage ein Ergebnis.

Die allereinfachste Abfrage sieht so aus: 

 <Query>
  <ElementPath IgnoreNamespaces="true">
<ElementNode>
<XMLName>
*
</XMLName>
</ElementNode>
</ElementPath>
</Query>

Durch die Angabe des Sternchens * versucht der Query Designer zu ermitteln, welche Elemente & Attribute selektierbar sind; da die XML Strukture des RSS Feeds etwas komplexer sind und ein paar Namespaces verwendet werden, funktioniert es nicht so gut. Bessere Ergebnisse erzielt man, wenn man explizit ElementPath & ElementNodes angibt, dadurch werden aber auch mehrere Dataset’s benötigt, um alle Daten zu erhalten. Hier mal ein Beispiel für die Forecast Nodes der XML Daten:  

 <Query xmlns:yweather="http://xml.weather.yahoo.com/ns/rss/1.0"
 xmlns:geo="http://www.w3.org/2003/01/geo/wgs84_pos#">
 <ElementPath IgnoreNamespaces="true">
 <ElementNode>
 <XMLName>
 rss{}/channel{}/item{}/forecast
 </XMLName>
 </ElementNode>
 </ElementPath>
</Query> 

Es werden zunächst die Namesspaces definiert und dann gezielt über ElementPath + ElementNode die gewünschten Elemente adressiert. Man erhält nun ein Dataset mit Feldern je Element, wobei das letzte Feld immer dem ElementNode-Namen entspricht und keine Daten enthält.

Ein Dataset haben wir nun und mit dem kann man nun eine Table auf dem Report anlegen, um die Daten anzuzeigen. Wie erwähnt müssen weitere Dataset’s je Element-Hierarchie angelegt werden, um weitere Daten aus dem XML Ergebnis zu selektieren. Das ist soweit kein Problem, nur etwas Fleißarbeit.

So, bisher war die URL fix für eine WOEID hinterlegt, wünschenswerte wäre aber, die Wettervorhersage auch für andere Orte abrufen zu können. Dazu lege ich einen Parameter namens WOEID mit einer festen Werteliste an; Default setze ich wieder auf Hannover.

Die Verbindungszeichenfolge muss dann von einem festen Werte auf einen „Ausdruck“ geändert werden, der sieht so aus:

= "http://weather.yahooapis.com/forecastrss?u=c&w=" & Parameters!WOEID.Value

also nichts anderes als die Basis URL mit der WOEID als variabler Teil. Nach der Änderung funktionieren aber die Abfragen im Query Designer nicht mehr, deswegen sollte man diese Anpassung erst ganz zu Letzt machen.

Das Ergebnis sieht so aus und kann wie üblich von meinem SkyDrive heruntergeladen werden, Anpassungen sind dieses Mal eigentlich nicht nötig, da die sonst variable Datenquelle hier fix ist; eben die Yahoo URL. 

Ein nettes Gimmick, dieser Wetterbericht. Es ist wirklich kein Must-Have, aber wenn man eh schon einen Reporting Service im Einsatz hat, kann man den Report doch auch mit veröffentlichen; frisst ja kaum Brot. 

Dann noch eine Subsription mit PDF Versand per Email und schon muss man nicht mehr die Nachrichten hören, um die aktuelle Wettervorhersage zu erhalten. J

Und ich für meinen Teil werden nun weiter Ausschau nach freien Web APIs halten, die man für SSRS Berichte nutzen könnte.

Weiterführende Links bei MSDN:

-       XML-Abfragesyntax zum Angeben von XML-Berichtsdaten
-       Syntax für Elementpfade zum Angeben von XML-Berichtsdaten

Es ist natürlich nicht wirklich als Ersatz für das DatePicker Control für Datumsparameter gedacht, sondern mehr als kleines Gimmick und ist auch eher ein kleines Experiment, was so machbar ist im Microsoft Reporting Services.

Um einen Kalender abbilden zu können, werden natürlich zunächst einmal die Datumswerte für einen Bereich rund um ein vorgegebenes Datum benötigt. Damit man auch eine einfache Liste zu Darstellung verwendet werden kann, sollten die Daten nach Wochentagnamen pivotisiert sein. Das kann mit zwei Funktionalitäten vom Microsoft SQL Server erreicht werden: Eine Common Table Expression zum Erzeugen der Datenreihe und die Pivot Funktion um eine Kalenderwoche / Wochentag Matrix zu erhalten:

Statement: 

  -- Nur für Test in SSMS, für SSRS wieder entfernen
SET LANGUAGE DEUTSCH; -- Wegen fixen Wochentagnamen
DECLARE @startDate date; -- Parameter wie in SSRS definiert
SET @startDate = {d N'2011-01-03'};
;WITH 
dates AS
 (SELECT CAST(DATEADD(dd, -13 - DATEPART(dw, @startDate)
 , @startDate) AS date) as CalendarDate
 UNION ALL
 SELECT DATEADD(dd, 1, CalendarDate) as CalendarDate
 FROM dates
 WHERE CalendarDate < 
 DATEADD(dd, 14 + (7 - DATEPART(dw, @startDate)), @startDate)
 )
SELECT IsoWeek, [Montag], [Dienstag], [Mittwoch]
 , [Donnerstag], [Freitag], [Samstag], [Sonntag]
FROM
 (SELECT DATEPART(iso_week, CalendarDate) AS IsoWeek
 ,DATENAME(dw, CalendarDate) AS DayName
 ,CalendarDate
 FROM dates
 ) AS PivotSource
PIVOT (Min(CalendarDate)
 FOR DayName IN ( [Montag], [Dienstag], [Mittwoch]
 ,[Donnerstag], [Freitag], [Samstag], [Sonntag])
 ) AS PivotTable
ORDER BY [Montag], [Dienstag], [Mittwoch]
 , [Donnerstag], [Freitag], [Samstag], [Sonntag] 

  Ergebnis: 

 IsoWeek     Montag     Dienstag   Mittwoch   Donnerstag Freitag    Samstag    Sonntag
----------- ---------- ---------- ---------- ---------- ---------- ---------- ----------
51          2010-12-20 2010-12-21 2010-12-22 2010-12-23 2010-12-24 2010-12-25 2010-12-26
52          2010-12-27 2010-12-28 2010-12-29 2010-12-30 2010-12-31 2011-01-01 2011-01-02
1           2011-01-03 2011-01-04 2011-01-05 2011-01-06 2011-01-07 2011-01-08 2011-01-09
2           2011-01-10 2011-01-11 2011-01-12 2011-01-13 2011-01-14 2011-01-15 2011-01-16
3           2011-01-17 2011-01-18 2011-01-19 2011-01-20 2011-01-21 2011-01-22 2011-01-23

Da für die PIVOT Funktion fixe Werte für die Wochentage verwendet werden, funktioniert die Abfrage natürlich nur mit deutschen Spracheinstellungen und für die IsoWeek ist natürlich die DATEFIRST Einstellung wichtig; also komplett DE Settings. Als Aggregationsfunktion für PIVOT kann statt MIN auch jede andere Aggregation verwendet werden; es gibt ja nur ein Datum je Woche / Wochentag Gruppierung. Das Aufrechnen des DATEPART(dw,..) Wertes wird hier verwendet, um immer „volle“ Wochen zu erhalten. So enthält das Ergebnis immer die Woche, in der das Datum liegt und jeweils +/- 2 volle Wochen drum rum.

 Weiter geht’s mit dem Report. Da die Daten bereits wie gewünscht aufbereitet sind, reicht eben ein einfaches Listen Control für die Darstellung (abgesehen davon, dass in SSRS 2008/2008R2 eh alles ein Tablix ist). Um die Liste auch als interaktives Control verwenden zu können, wird einfach „Aktion“ Funktion bei den einzelnen Datumsfelder verwendet. Hier gibt man als „Gehe zu Bericht“ den gleichen Bericht wieder an und legt für den Parameter den Wert des aktuellen Feldes an; so wird der Bericht erneut mit dem neuen, angeklickten Datum aufgerufen.

Analog kann man über Textboxen / Images Funktionen wie „Heute“, „Vorjahr“ oder „Folgemonat“ umsetzen, nur das hier für den Parameter beim Berichtsaufruf eine Expression verwendet wird, wo auf dem aktuellen Datumsparameter per DateAdd ein Wert aufgerechnet wird bzw. fix auf Today() gesetzt wird.

Das BIDS 2008 Projekt kann von meinem SkyDrive geladen werden, es muss dann nur die Datenquelle angepasst werden, wobei die auch auf die master Datenbank zeigen kann; es wird ja aus keiner Tabelle selektiert, sondern nur eine CTE mit fixen Werten verwendet.

Eine Vorschau des Reports sieht so aus, optisch kann es ja nach Belieben gestaltet werden; die aufs Datum bezogenen Daten können dann unterhalb des Kalenders angezeigt werden:

Man muss ja nicht immer alles Nachmachen oder –programmieren, besonders nicht Features aus der Rubrik „Noch Bunter – Noch Greller“.

Die Funktion zur „Bedingten Formatierung“, die in MS Excel 2007 hinzugekommen ist, ist aber durchaus gut geeignet, um Werte und deren Größenordnung optisch hervor zu heben. Im MS Reporting Services kann man dieses ebenfalls abbilden, das setzt aber etwas Customer Code voraus.

Zum Testen nehme ich zunächst einmal eine einfache CTE mit fixen Werten für Umsatzzahlen her, die prozentualen Anteile am Jahresumsatz werden dann in einer weiteren CTE errechnet. Diese Prozentwerte will ich dann im Weiteren eben durch eine Hintergrundfarbe hervorheben.

 ;WITH 
 Umsatz AS 
( SELECT 'Kunde 1' As Customer, 15000 AS Ums2009, 17000 AS Ums2010
 UNION ALL
 SELECT 'Kunde 2', 23000, 22000 UNION ALL
 SELECT 'Kunde 3', 10000, 12000 UNION ALL
 SELECT 'Kunde 4', 39000, 32000 UNION ALL
 SELECT 'Kunde 5', 1000, 3000) 

 , Summe AS
( SELECT SUM(Ums2009) AS Total2009
 ,SUM(Ums2010) AS Total2010
 FROM Umsatz) 

 , Statistik AS
( SELECT Customer
 ,Ums2009
 ,Ums2010
 ,100 * Ums2009 / Total2009 AS Percentage2009
 ,100 * Ums2010 / Total2010 AS Percentage2010
 ,100 * (Ums2010 - Ums2009) / Ums2009 AS Raise 
 FROM Umsatz, Summe) 

 SELECT *
FROM Statistik; 

Nun brauch ich noch etwas Customer Code. Das Property „BackgroundColor“ erwartet entweder einen Farbnamen wie „Black“ für Schwarz oder einen RGB Werte als Hexadezimal Wert als String wie #FF0000 für einen Rotwert. Letzteres nutze ich, um einen Farbwert passend zum Prozentwert zu errechnen. Der Code, um einen Rotwert analog in der Helligkeit zum Prozentwert zu errechnen, sieht so aus:

 ' Liefert einen Rot-Farbwert als Hexadezimal-Wert (String) zu den übergebenen Prozentwerten 

 Public Function PercentageRed(ByVal percentage As Decimal) As String 

  ' Wert muss zwischen 0 und 100 sein; sonst zur Sicherheit auf Default Werte setzen 

  If percentage < 0 Then percentage = 0
 If percentage > 100 Then percentage = 100 

   Dim value As Integer 

  value = CInt(255.0 * (100.0 - percentage) / 100.0) 

   ' #FF = Rot als Basis
 Return "#FF" & value.ToString("X2") & value.ToString("X2") 

 End Function 

Also wirklich Karo-Einfach, den maximalen Byte-Wert von 255 ins Verhältnis gesetzt zum Prozentwert. Damit hohe Prozentwerte dunkel dargestellt werden, wird vom Prozentwert das Inverse gebildet.

Im Report setzte ich dann als Beispiel für die Textbox „Percentage2010“ das Property „BackgroundColor“ auf „Expression“ und füge nur noch das folgende Expression ein:

=Code.PercentageRed(Fields!Percentage2010.Value)

Das Ergebnis sieht dann so aus; für das bisschen Customer Code doch ganz gut, oder?

Die Microsoft Business Intelligence Developer Studio (BIDS) Standard Vorlagen für Reporting Projekte sind nicht so ganz optimal, wie ich finde. Die Report Vorlage selbst ist im Letter Format mit Inches Angaben und die Textgrößen bei Tablix & Co, die vom Wizard erstellt werden, finde ich etwas sehr groß.

Hinzu kommt, das man im Sinne von Corporate Identity bestimmt Elemente wie Header-Logo oder eine Footer-Zeile mit Standard-Infos immer gleich platziert und die Mühe möchte man sich eigentlich sparen.

Diese Standard Vorlagen kann man aber einfach an seine Vorstellungen anpassen; vorher aber immer eine Sicherheitskopie der Dateien erstellen!

Report Projekte Vorlage

Die Vorlage für Report Projekte fürs BIDS 2008 findet man in:

%ProgramFiles%\Microsoft Visual Studio 9.0\Common7\IDE\PrivateAssemblies\ReportProjects\ReportProject.rptproj

Die Standard Vorlage ist eher leer und viel zum Anpassen gibt es auch nicht, aber man kann schon mal die Ziel-Url vom verwendeten SSRS angeben; halt all die Konfigurationswerte, die man in den Projekt-Eigenschaften festlegt.

<?xml version="1.0"?>
<Project xmlns:xsi="http://www.w3.org/2000/10/XMLSchema-instance" 
         xmlns:xsd="http://www.w3.org/2000/10/XMLSchema">
  <DataSources />
  <Reports />
  <!-- Mein Anpassung -->
  <Configurations>
    <Configuration>
      <Name>Debug</Name>
      <Platform>Win32</Platform>
      <Options>
        <TargetServerURL>http://MeinServer/Reportserver_InstanzenName

        </TargetServerURL>
      </Options>
    </Configuration>
    <Configuration>
      <Name>Release</Name>
      <Platform>Win32</Platform>
      <Options>
        <TargetDataSourceFolder>Datenquellen</TargetDataSourceFolder>
      </Options>
    </Configuration>
  </Configurations>
  <!-- Ende Anpassung -->  
</Project>

Report Vorlage

Liegt in

%ProgramFiles%\Microsoft Visual Studio 9.0\Common7\IDE\PrivateAssemblies\ProjectItems\ReportProject\Report.rdl

und ist eine ganz normale RDL Datei, die man entsprechend auch mit BIDS bzw. dem Report Builder 2.0 bearbeiten kann, also kein kryptische XML Bearbeitung.

Hier kann man also schon mal das gewünschte Seitenformat vorgeben, ein Logo einfügen, Seitenfuß festlegen und so weiter. Selbst Custom Code, Assemblies und Classes können hier schon eingefügt werden. Wenn man dann in seinem BIDS Projekt einen neuen Report hinzufügt, wird diese RDL Datei als Vorlage kopiert. Der Report Builder verwendet diese Vorlage nicht, ob und von wo der eine Vorlage zieht, ist mir nicht bekannt, im Internet war auch nichts zu dem Thema auffindbar.

Styles Vorlage

Die Vorlage für Styles liegt in

%ProgramFiles\Microsoft Visual Studio 9.0\Common7\IDE\PrivateAssemblies\Business Intelligence Wizards\Reports\Styles\de\StyleTemplates.xml

Hier ist also wieder XML Bearbeitung angesagt, da empfiehlt es sich, einen XML Editor zu verwenden.

Am besten ist es, man kopiert einen vorhandenen <StyleTemplate> Block, gibt diesen einen neuen, eindeutigen Namen und bearbeitet dann die Werte.

Die Struktur der Styles wird schnell ersichtlich, man kennt es bereits, wenn man schon per Wizard ein Tablix angelegt hat. Man kann je Verschachtelungstief 1 – 3+ (Group Level) die Formatierung definieren. Dabei kann man alle Properties angeben, die man auch aus BIDS kennt. Man muss nur beachten, das XML immer Case Senstive ist, man muss also Groß-/Kleinschreibung beachten.

Die Vorschaufunktion im Wizard funktioniert zwar nicht mit den selbst definierten Styles, aber das stellt nun wirklich kein Beinbruch dar.

Hier mal ein Beispiel, bei dem ich für den Report „Title“ das TextAlign=Center setze:

<StyleTemplate Name="Olaf">
  <Label>Olaf</Label>
  <Styles>
    <Style Name="Title">
      <FontFamily>Arial</FontFamily>
      <FontSize>20pt</FontSize>
      <Color>MidnightBlue</Color>
      <FontWeight>Bold</FontWeight>
      <TextAlign>Center</TextAlign>
    </Style>
    <...

Auf Websites sieht man häufiger Übersichtsseiten (Index) mit Links zu allen vorhandenen Seiten. Das ist sehr praktisch, man kann auf der Seite selbst nach Begriffen suchen und schnell auf Seiten navigieren, ohne sich lange durch diverse Menüs hangeln zu müssen.

Für eine umfangreiche Report Sammlung im Microsoft SQL Server Reporting Services wäre so was auch nicht verkehrt, also gehen wir das mal an.

Alle hierfür benötigten Daten sind in der ReportServer Datenbank in der Tabelle dbo.Catalog vorhanden.
Das Feld „Type“ kennzeichnet die Objektart, hierbei sind 1 = Folder und 2 = Report für die Übersicht von Interesse, 4 = verlinkte Reports lassen wir mal aus. Über die „ItemId“ und „ParentId“ wird die hierarchische Struktur abgebildet. Hier bietet sich einem zur Abfrage natürlich eine rekursive CTE (Common Table Expression) an. Es wird zunächst das Root Element selektiert (ParentID IS NULL) und dann alle Children über einen JOIN mittels ItemId = ParentID auf CTE selbst.

 In der Übersicht soll dann auch eine Jump-to Action möglich sein, um zum Report springen zu können. Dafür kann man die Daten aus dem Feld „Path“ verwendet werden, es enthält die relative Pfadangabe des Elementes. Bei der Selektion wird der „Path“ bereits so modifiziert, um die Daten für einen HyperLink im Report verwenden zu können. Es muss dabei nur ein paar Kleinigkeiten beachtet werden, so müssen (gemäß Url Regel) die Slash’s durch %2f und Leerzeichen durch ein Pluszeichen ersetzt werden. Zudem müssen Berichte über „/Reports.aspx“ und Ordner entsprechend über „/Folder.aspx“ aufgerufen werden.  

 Schlussendlich, um es halbwegs gemäß der Hierarchie sortieren zu können, muss der Pfad des übergeordneten Elementes als primäre Sortierung verwendet werden; dank CTE kann das aber problemlos mitselektiert werden. 

 So sieht nun die Selektion der benötigten Daten als CTE aus: 

 -- Selektion aller vorhandenen Folder und Reports 

 -- über eine rekursive CTE  

 DECLARE @url varchar(100); 

 -- Url vom ReportManager; muss entsprechend angepasst werden 

 SET @url = 'http://MyServer/Reports_MyInstanz/Pages/§§§ReportOrFolder§§§.aspx?ItemPath='; 

 ;WITH RPT AS 

 ( -- Root Pfad 

  SELECT RT.ItemID 

  ,RT.Path 

  ,RT.ModifiedDate 

  ,0 AS [Level] 

  ,CAST(N'Stamm' AS nvarchar(425)) AS ReportName 

  ,CAST(N'Stamm' AS nvarchar(425)) AS ParentFolder 

  ,RT.Path AS ParentPath 

  ,REPLACE(REPLACE(RT.Path, '/', '%2f'),' ', '+') AS ReportLink 

   ,RT.Type AS ObjType 

  FROM dbo.Catalog AS RT 

  WHERE RT.ParentID IS NULL 

  AND RT.Type = 1 -- Nur den Root Folder 

  UNION ALL 

  SELECT CHILD.ItemID 

  ,CHILD.Path 

  ,CHILD.ModifiedDate 

  ,RPT.[Level] + 1 AS [Level] 

  ,CHILD.Name AS ReportName 

  ,CASE WHEN CHILD.Type = 1 THEN CHILD.Name ELSE RPT.ReportName END AS ParentFolder 

  ,CASE WHEN CHILD.Type = 1 THEN CHILD.Path ELSE RPT.ParentPath END AS ParentPath 

  ,REPLACE(REPLACE(CHILD.Path, '/', '%2f'),' ', '+') AS ReportLink 

   ,CHILD.Type AS ObjType  

  FROM dbo.Catalog AS CHILD 

  INNER JOIN  

  RPT ON CHILD.ParentID = RPT.ItemID 

  WHERE CHILD.Type = 2 -- Alle Reports und nur nicht-leere Folders 

  OR (CHILD.Type = 1 

  AND EXISTS (SELECT 1 FROM dbo.Catalog AS SUB 

  WHERE SUB.Type IN (1, 2) 

  AND SUB.ParentID = CHILD.ItemID)) 

 ) 

 SELECT RPT.Path 

  ,RPT.ReportName 

  ,CASE WHEN RPT.ObjType = 1 THEN REPLACE(@url, '§§§ReportOrFolder§§§', 'Folder') 

  ELSE REPLACE(@url, '§§§ReportOrFolder§§§', 'Report') 

  END 

  + RPT.ReportLink 

  + CASE WHEN RPT.ObjType = 1 THEN '&ViewMode=List' ELSE '' END 

  AS Link 

  ,RPT.ObjType 

  ,RPT.ModifiedDate 

  ,RPT.Level 

  ,RPT.ParentFolder 

  ,RPT.ParentPath 

 FROM RPT 

 ORDER BY RPT.ParentPath 

  ,RPT.Path 

  ,RPT.ReportName; 

Der Report für die Übersicht habe ich zunächst recht einfach als eine Tabelle mit 2 Zeilen, eine für Ordner und eine für Berichte, gestaltet. Die Zeilen werden dann je nach „ObjType“ sichtbar geschaltet.

Eine optische „Hierarchie-Tiefe“ der Elemente wird über die Padding - Left Eigenschaft der Textbox erreicht; hier wird über einen Ausdruck der Wert des CTE Feldes „Levels“ gesetzt und so das Feld nach rechts verrückt.

Als „Action“ wird dann „Gehe zu Url“ verwendet, das an die Daten der Selektion-Feldes „Link“ gebunden wird.

Und das Ergebnis sieht dann so wie unten aus. Zugegeben, man kann das optisch noch attraktiver gestalten, da kann jeder seiner Kreativität freien Lauf lassen. Wenn die Reportnamen nicht zu lang und die Strukturebene nicht zu tief ist, könnte man den Bericht auch in 2 Spalten gliedern, um Platz zu sparen.

Der Report kann als „ReportOverview.rdl“ Datei fürs BIDS 2008 bzw. Report Builder 2.0 von meinem SkyDrive herunter geladen werden:

In Reports mit dem MS SQL Server - Reporting Services zu Artikellisten möchte man zuweilen gerne zugehörige Bilder anzeigen lassen,  ähnlich wie in einem Katalog. Eine Variante der Bildablage ist es als BLOB in der Datenbank selbst, die andere ist das Speichern des Dateinamen nebst Ablageordner. Dabei gibt es aber etwas zu beachtet

-  Der Account, unter dem der „SQL Server Reporting Services“  Dienst läuft, muss natürlich zumindest Lesezugriff auf die Bild-Dateien habe.

-  Der Dateiname + Pfad muss als URL mit file://... angegeben werden.

Hier dazu ein Beispiel mit Bilder aus dem lokalen Windows-Verzeichnis; habe ich nur auf meinem Arbeitsplatzrechner getestet und nicht auf einem Server; aber auch dort sollten sich Bilder finden lassen.

Zunächst einmal eine Demo-Tabelle mit ein paar Datensätze:

 
 CREATE TABLE [dbo].[Bilder]( 

  [ID] [int] IDENTITY(1,1) NOT NULL, 

  [Bild] [varchar](255) NULL 

 ) ON [PRIMARY] 

 GO 

 INSERT INTO Bilder VALUES ('file://C:\Windows\Web\Wallpaper\img1.jpg'); 

 INSERT INTO Bilder VALUES ('file://C:\Windows\Web\Wallpaper\img2.jpg'); 

 INSERT INTO Bilder VALUES ('file://C:\Windows\Web\Wallpaper\img3.jpg'); 

 GO 

Nun im BIDS einen neuen Report mit der Tabelle als DataSet anlegen, eine Liste oder Tablix als Control auf den Report platzieren, die Felder „ID“ und „Bild“ dort einfügen; eigentlich mehr zur Kontrolle. Dann eine weitere Spalte einfügen und in die ein „Bild“ Control reinziehen. In den Bildeigenschaften gibt man dann noch folgendes an

-  Bildquelle auswählen = Extern

-  Diese Bild verwenden = [Bild]  (also der Feldname aus dem DataSet)

Das war es schon.

Wie schon erläutert, kann man sich für das SSMS (SQL Server Management Studio) benutzerdefinierte Bereichte erstellen, um sich Ergebnisse optisch aufbereiten zu lassen und nicht immer nur als tabellarischen Resultset zu bekommen.

Um nicht für jeden neuen Report die Parameter nebst Definition wieder erfassen zu müssen, habe ich mir ein Template fürs BIDS 2005 (Business Intelligence Developer Studio) erstellt, das es hier gibt. Man kopiert es einfach, benennt es um und bindet es in seine BIDS 2005 Solution ein; schon kann es losgehen. Nutzt man BIDS 2008, wird der Report konvertiert, vom Original eine Sicherungskopie erstellt.

Als erstes Beispiel, das man auch praktisch Verwenden kann, gibt es die Auswertung „Databases in Usage“. Es listet alle Datenbanken der Instanz mit der Anzahl der User + Prozessen, die die Datenbanken verwenden. Nicht verwendete Datenbanken werden gegraut angezeigt.

Der Report beruht auf der einfachen Abfrage:

 SELECT DB_NAME(DBS.dbid) AS DatabaseName, 
 PRO.dbid,
 COUNT(PRO.spid) AS CntSPID,  

  COUNT(DISTINCT PRO.loginame) AS CntUser, 
  COUNT(DISTINCT PRO.hostname) AS CntHost, 

  SUM(PRO.cpu) AS SumCpu, 
  SUM(PRO.physical_io) AS SumIO, 
  SUM(PRO.memusage) AS SumMem 

 FROM master.sys.sysdatabases AS DBS 

  LEFT JOIN master.sys.sysprocesses AS PRO 

  ON DBS.dbid = PRO.dbid 

 GROUP BY DB_NAME(DBS.dbid), PRO.dbid 

 ORDER BY DB_NAME(DBS.dbid)