Ich möchte in diesem Blogbeitrag erklären, wie man Surrogate-Keys für Parent-Child-Hierarchien und die jeweilige Hierarchiestufe des Mitarbeiters anlegen kann. Dabei hilft uns die Angestellten Tabelle der AdventureWorks Datenbank. Diese findet man unter dem Tabellennamen Employee im Schema HumanResources. Der Mitarbeiter wird über die Spalte EmployeeID identifiziert und der Vorgesetzte über die Spalte ManagerID. Angestellte die keinen Vorgesetzten haben, sind mit entsprechender ManagerID auf NULL gesetzt. Dementsprechend ist der/sind die Mitarbeiter der/die keinen Vorgesetzten hat/haben, die höchste Stufe in unserer Organisation (in unserem Fall also der Chef).

Wir müssen in unserer Tabelle in der später unsere Daten landen sollen zunächst zwei zusätzliche Spalten einfügen. Das wäre zum einen die Spalte EmployeeBK und ManagerBK. Die Erklärung dazu folgt dann später im Text.

Außerdem benötigen wir in unserer Ausgangstabelle (Employee) eine Hilfsspalte (ich habe mich i.F. für istImportiert entschieden (NULL ist zulässig)) mit beliebigen Namen und dem Datentyp bit.

Als nächstes müssen wir dafür sorgen, dass alle Werte in dieser neuen Spalte den Wert 0 enthalten. Damit das Ganze gleich in SSIS passiert, ziehen wir uns einen SQL-Task auf unsere Arbeitsfläche und fügen den Befehl update [HumanResources].[Employee] set istImportiert = 0 ein.

Für den nächsten Schritt benötigen wir eine Laufvariable mit dem Datentyp Integer und dem Standardwert 0. Danach legen wir einen for-Schleifencontainer an. Nachdem Ihr die Eigenschaften festgelegt habt, legen wir einen Datenflusstask in den Container.

Vorweg schon mal die Ansicht, wie es später in unserem Datenflusstask aussehen wird:

Schritt 1

Wie üblich brauchen wir zunächst eine Quelle. Entscheidend ist hier natürlich, dass wir neben der ManagerID und der EmployeeID die Abfrage darauf einschränken, dass nur Daten geladen werden, wo der Wert für istImportiert = 0 ist.

Schritt 2

In der Komponente für bedingtes Teilen erfolgt die Überprüfung, welche Daten unsere Wurzelknoten (also unsere Manager mit dem Eintrag null) sind. Alle anderen Mitarbeiter werden als Knoten ausgegeben.

Schritt 3

Wir kümmern uns zunächst um die Mitarbeiter, die unseren Wurzelknoten repräsentieren. Dazu legen wir eine Abgeleitete Spalte mit dem folgenden Ausdruck an:

Im zweiten Teil von Schritt 3 müssen die anderen Hierarchiestufen überprüft werden. Hierfür legen wir eine Lookup Komponente an und verbinden diese mit der Ausgabe für Knoten aus der Conditional-Split Komponente. Damit wir es später nicht vergessen, ändern wir unter Allgemein die Einstellung wie nicht getroffene Einträge behandelt werden (auf Fehler ignorieren stellen). Unter Verbindung fügen wir ein SQL-Statement ein, das unsere Tabelle abfragt, in der letztendlich unsere Daten landen sollen. Jetzt kommt eine der erwähnten Spalten aus der Einleitung ins Spiel. EmployeeBK enthält später die Mitarbeiternummer welche aus EmployeeID kommt.

Wir verknüpfen die ManagerID mit EmployeeBK und lassen uns die EmployeeID (im SQL-Statement umbenannt zu EmployeeParentID) ausgeben. Überall wo wir keinen Treffer haben, wird NULL ausgegeben.

Schritt 4

Mit dem nächsten Conditional Split überprüfen wir, ob EmployeeParentID einen Wert erhalten hat oder nicht. Alle Zeilen für die es einen Treffer gibt, gehen in diesem Beispiel an die Ausgabe „Vater gefunden“.

Schritt 5

Mit Hilfe einer Union All Komponente verknüpfen wir die eingehenden Zeilen.

Schritt 6

Über die Multicast Komponente lassen wir uns Kopien des Datasets erzeugen.

Schritt 7

In der Komponente OLE DB Befehl fügen wir für unsere Quelltabelle Employee ein Update Statement ein.

Außerdem muss in den Spaltenzuordnungen EmployeeID mit Param_0 verknüpft werden.

Schritt 8

Als Erstes betrachten wir die Zuordnungen für unser Ziel (OLE_DST EmployeeNeu). Wie bereits erwähnt, stellt die EmployeeID in unserer Zieltabelle den Surrogate-Key dar. Außerdem muss darauf geachtet werden, dass unsere EmployeeParentID mit der ManagerID verknüpft wird.

Da wir uns immer noch im Schleifencontainer befinden, müssen wir im letzten Schritt dafür sorgen, dass kein Durchlauf mehr erfolgt, wenn unsere Laufvariable einen Wert ungleich 0 hat. Wir fügen eine Komponente „SQL ausführen“ (SQL UPDATE Employee) ein (siehe Bild)

und legen folgende Einstellungen fest:

Wenn noch nicht geschehen, muss im ResultSet unsere Laufvariable ausgegeben werden.

Hierarchiestufe

Da ich abschließend wissen möchte, wie viele Vorgesetzte ein Mitarbeiter über sich hat, benötige ich eine zusätzliche Variable, die für jeden Durchlauf des Containers hochgezählt und dann in unsere Zieltabelle weggeschrieben wird. Hierfür lege ich zunächst eine Variable (iHierarchiestufe) mit dem Datentyp integer an (Startwert steht auf 1) und ergänze meine Zieltabelle um die Spalte Hierarchiestufe. Den Wert der Variablen füge ich mit Hilfe der Komponente „abgeleitete Spalte“ in eine neue Spalte ein.

Außerdem muss ich noch das Mapping wie in Schritt 8 beschrieben ergänzen falls nicht schon geschehen.

Natürlich muss dem Schleifencontainer noch mitgeteilt werden, dass unsere Variable pro Durchlauf hochgezählt wird (AssignExpression). Die Einstellung dafür bitte dem Bild For-Schleifen-Editor entnehmen.

Abschließend schauen wir uns noch das Ergebnis für unsere Zieltabelle „EmployeeNeu“ an. Im ersten Durchlauf finden wir genau einen Mitarbeiter der keinen Vorgesetzten hat. Er steht dementsprechend an erster Stelle in der Hierarchie.

Erster Durchlauf:

Im zweiten Durchlauf (zweite Ebene in der Hierarchie) haben wir schon mehr Mitarbeiter getroffen. Die ehemalige EmployeeID aus der Quelltabelle befindet sich nun in der Spalte EmployeeBK. Unter ManagerBK finden wir die zugehörige Kennzeichnung des Vorgesetzten (ManagerID aus der Quelltabelle). Unter ManagerID befindet sich der neu erzeugte Surrogate Key.

Zweiter Durchlauf:

Da alle weiteren Hierarchiestufen nach dem gleichem Schema gefüllt werden, spare ich mir an dieser Stelle die Fotos für die nächsten Durchläufe. Viel Spaß beim Ausprobieren.

Wenn ich euch mit dieser Anleitung helfen konnte, ihr weitere Fragen, Anmerkungen, Verbesserungsvorschläge oder Lösungen habt, freue ich mich auf Kommentare!

Auf die Property kann nicht direkt zugegriffen werden. Stattdessen wird der Property ExecValueVariable eine Package-Variable zugeordnet. In diese wird dann zur Laufzeit des Paketes die Anzahl der Zeilen, die von der ausgeführten SQL-Anweisung betroffen waren, eingetragen. Diese Variable kann im weiteren Package-Ablauf verwendet werden. Für die Anzahl der Zeilen wird eine Int-Variabel verwendet, die in disem Beispiel iExecValue genannt wird.

Als nächstes wird ein Execute-SQL-Task erstellt, der die Beispiel-Tabelle Example mittels einer DELETE-Anweisung leert. Die Tabelle enthält 3 Datensätze und somit erwarten wir die Zahl 3 als Anzahl der betroffenen Zeilen. Im Editor des Tasks wird die Connection ausgewählt und die Anweisung „DELETE FROM Example“ als Direkteingabe eingegeben.

Durch Rechtsklick auf den Task und Auswahl von „Eigenschaften“ wird der Eigenschaften-Editor des Tasks geöffnet. Da wird der Property ExecValueVariable über die Dropdpwn-Liste die vorher angelegte Variabel iExecValue aus.

Um nach Start des Paketes das Ergebnis zu prüfen, setzen wir einen Breakpoint auf das PostExecute-Ereignis des Tasks (Rechtsklick auf den Task, Haltepunkte bearbeiten wählen und dann den Eintrag für „OnPostExecute“ anhaken). Damit kann direkt nach Ausführung des SQL-Tasks geprüft werden, ob die Variable tatsächlich die gewünschte Anzahl der betroffenen Zeilen enthält.

Anschließende wird das Paket ausgeführt. Bei Erreichen des Breakpoints fügen wir über Debuggen->Fenster->Überwachungsfenster1. Dort tippen wir in die Namensspalte den Namen unserer Variabel ein. Anschließend sehen wir, dass unsere Variable tatsächlich die Anzahl der von der SQL-Anweisung betroffenen Zeilen enthält:

#

Es kann auch eine Stored Procedure aufgerufen werden, die wie in unserem Beispiel eine DELETE-Anweisung ausführt. In der Stored Procedure darf dann nicht SET NOCOUNT ON“ verwenden, da dann die Zahl der betroffenen Zeilen nicht ermittelt wird.

In dem Beispiel kann TRUNCATE nicht verwendet werden, da bei TRUNCATE nicht zeilenweise gelöscht wird, wie bei DELETE. Bei TRUNCATE werden stattdessen die Datenseiten der betroffenen Tabelle deallokiert.

In diesem Beitrag möchte ich eine Möglichkeit erläutern, die so simpel ist, dass der ein oder andere vielleicht gar nicht erst daran gedacht hat – frei nach dem Motto: „Ich seh‘ den Wald vor lauter Bäumen nicht“.

Nehmen wir an, es handelt sich bei unserer Zahl um einen Prozentwert, dessen Anzahl der Nachkommastellen wir auf 5 begrenzen und im Falle der Überschreitung einen Fehler ausgeben lassen wollen (z.B. wenn die Zielspalte in der Datenbank nicht mehr als 5 zulässt). Dies würde sich zwar mit einfachen Mitteln realisieren lassen, jedoch unter Umständen nicht immer zum gewünschten Ergebnis führen.

Angenommen es handelt sich um den Wert 12,1234500 – so würden die beiden letzten Nachkommastellen nach „Schema-F“ abgeschnitten und ein Fehler erzeugt werden. Da es sich in diesem Falle aber um das Abschneiden von lediglich zwei nullen handelt und somit der numerische Wert trotzdem unverändert und somit gültig bleibt, muss hier eine andere Lösung her.

Wie? Ganz einfach! Man vergleiche die Zahl mit sich selbst – und zwar konvertiert in einen Gleitkommawert mit 5, sowie mit 6 Nachkommastellen. Das ganze könnte dann z.B. so aussehen:

(DT_NUMERIC, 10, 5)Wert == (DT_NUMERIC, 10, 6)Wert

Die folgende Abbildung sollte das Prinzip noch einmal veranschaulichen und weitere Erläuterungen überflüssig machen

Das Problem begegnet uns immer dann, wenn in der Datenbank Werte in einer anderen Granularität gespeichert werden (in diesem Fall monatsgenau) als diese von der darauf aufsetzenden Anwendung geliefert werden (diese erlaubt nur jahresgenaue Werte). Für spätere Auswertungen oder Änderungen möchten wir monatsgenaue Werte speichern, ohne den korrekten Jahreswert (die Summe der 12 Monate) zu verlieren.

Auch hier führen wieder viele Wege nach Rom, daher zeige ich im ersten Teil neben der eigentlichen Problemstellung und dem Kern der Lösung eine von vier (!) Möglichkeiten die ich gefunden habe um die Aufgabe zu lösen.

Zunächst einmal überlege ich mir geeignete Ausdrücke um die oben genannte Anforderung innerhalb eines SSIS-Datenfluss’ umsetzen zu können. Für die Monate 1 bis 11 genügt folgender Ausdruck:

(DT_NUMERIC,6,2)(Value / 12)

Der Monat 12 erfordert eine Sonderbehandlung, welche durch folgenden Ausdruck gewährleistet wird:

(DT_NUMERIC,6,2)(Value – (DT_NUMERIC,6,2)(11 * (DT_NUMERIC,6,2)(Value / 12)))

Im Grunde ermittelt dieser Ausdruck die Differenz zwischen dem Jahreswert und der Summe der 11 Monatswerte um den Wert für Monat 12 zu berechnen. Beachten Sie dabei, dass es egal ist ob bei der Ermittlung der Monatswerte ab- oder aufgerundet oder gar abgeschnitten wird (was hier der Fall ist), der Wert für Monat 12 wird stets korrekt ermittelt.

Einer der naheliegendsten Wege um diese Logik umzusetzen ist die Nutzung eines Cross Joins zwischen dem Jahreswert und 12 Monaten. Damit wird der Jahreswert von einer Zeile auf 12 Zeilen verteilt. Anschließend kann in einem “Abgeleitete Spalte”-Task der Wert mit Hilfe der oben beschriebenen Ausdrücke manipuliert werden.

Folgender Screenshot zeigt den Datenfluss und zwei Data Viewer: einen nach dem Cross Join und einem nach dem Anwenden der Ausdrücke. Beachten Sie, dass sich der Wert für Monat 12 von allen anderen unterscheidet um einen korrekten Jahreswert zu gewährleisten.

Im zweiten Teil zeige ich drei (!) weitere Vorgehensweisen, sowie die Ergebnisse eines Performancetests um zu ermitteln, wie sich die unterschiedlichen Wege im produktiven Einsatz bewähren könnten.

Die Datenbank

Zunächst sollte Klarheit darüber herrschen, welche Datenbankobjekte übertragen werden müssen. Vorbildliche Naturen können diese Frage mit einem Blick in die Historie ihrer professionellen Versionsverwaltung (natürlich inklusive Application LifeCycle Management) sogar des Nächtens im Halbschlaf beanworten (vielleicht haben sie auch mit Zettel und Stift mitgeschrieben), aber auch wenn diese Professionalität des Vorgehens nicht erreicht werden kann oder soll, gibt es es nützliche Hilfsmittel, die uns auf unter die Arme greifen helfen. Das OpenSource-Tool OpenDBDiff bietet die Möglichkeit, zwei Datenbank-Stände miteinander zu vergleichen. Es entsteht dabei ein SQL-Skript, dass ausgeführt auf der Zieldatenbank die ausgewählten Objekte synchronisiert. Dabei sei angemerkt, dass hierbei eigentlich nur Tabellenobjekte kritisch sind, da sich alle anderen, wie Views, Stored Procedures und User-Defined Functions, auch durch Löschen und Neu-Anlegen auf den gleichen Stand bringen lassen. Aber wenn wir OpenDBDiff ohnehin gestartet haben, sparen wir uns die Mühe.

Der zweite Schritt besteht im Abgleich von Steuerdaten, die zumeist in Konfigurationstabellen schlummern. Dazu kann uns das Tool TableDiff dienen, mit dessen Hilfe Unterschiede in Tabellendaten abgeglichen werden, indem auch hier SQL-Skripte generiert werden. Das Tool ist Bestandteil der SQL Server Installation und lässt sich zumeist unter C:\Program Files\Microsoft SQL Server\100\COM finden und aufrufen, wobei der Pfad je nach SQL Server Version und dessen Installationsverzeichnis varieren kann. TableDiff geht dabei tabellenweise vor, weshalb es sich anbietet, eine Batchdatei zu programmieren, die den Aufruf pro Tabelle automatisiert.

rem Server festlegen

set sserver=localhost

set dserver=localhost

rem Datenbanken festlegen

set sdb=AdventureWorksDW

set ddb=AdventureWorksDW2008

rem Pfade definieren

set exepath=”C:\Program Files\Microsoft SQL Server\100\COM\tablediff.exe”

set destfolder=D:\SQL

rem Schema festlegen

set schema=dbo

for %%t in (dimCurrency dimScenario) do (

%exepath% /sourceserver %sserver% /sourcedatabase %sdb% /sourceschema %schema%  /sourcetable %%t /destinationserver %dserver% /destinationdatabase %ddb% /destinationschema %schema% /destinationtable %%t -f “%destFolder%\changeScript(%schema%_%%t).sql”

)

Wir haben nun eine Reihe von SQL-Skripten, die nur noch auf der Zieldaten ausgeführt werden müssen, um die Datenbankstruktur in einen identischen Zustand zu bringen.

SSIS-Pakete und Cube-Defintionen

Es gilt nun, sowohl SSIS-Pakete und Cube-Definitionen zu übertragen. Dies ist etwas einfacher, da sowohl für SSIS- als für SSAS-Projekte einen Deployment-Wizard existiert, der uns das Bereitstellen auf dem Zielsystem (fast) vollständig abnimmt. Im Falle von SSIS-Paketen besteht weiterhin die Möglichkeit, auf das Kommandozeilenwerkzeug dtutil zurückzugreifen, das, eingebettet in eine Batch-Datei, das Bereitstellen der Pakete nach einem Doppelklick automatisch übernehmen kann. Da wir selbst in kleineren Projekten intensiven Gebrauch von der SSIS-Paketkonfiguration machen, haben wir auch wenig Mühe damit, Informationen wie Server- oder Datenbanknamen zu aktualisieren. SSAS-Cubes  müssen nur noch verarbeitet werden und sind damit direkt bereit zum Einsatz. Aber auch hier gilt es, eine gewisse Vorsicht an den Tag zu legen, da doch der ein oder andere Fallstrick lauert. Einer dieser Fallstricke sind Cube-Rollen, die ohne weitere Konfiguration auf dem Zielserver überschrieben werden. Doch auch wenn wir dies explizit verhindern wollen (die entsprechende Option im Deployment Wizard heißt Retain Roles und Members), ist leider nicht immer gewährleistet, dass die bestehende Konfiguration erhalten bleibt. Hier hat sich der Workaround etabliert, die Rollendefinition auf dem Produktivserver zu sichern (Zu finden im entsprechenden Bereich in der XMLA-Datei, also der Datenbankdefinition, auf der SSAS-Datenbank) und nach dem Deployment zurückzuspielen.

Die Berichte

Für SSRS-Berichte hat sich ein ein Werkzeug bewährt, dass es uns ermöglicht, Berichte direkt vom (Test)Berichtsserver herunterzuladen und auf den (Produktiv)Berichtsserver zu übertragen. Dazu wird neben den Berichtsdefinitionen in Form von .rdl-Dateien eine Batchdatei generiert, in der nur noch die URL des Zielsystems hinterlegt werden muss. Nach einem Doppelklick können wir und zurücklehnen und die Deployment-Show genießen.

Fazit

Mit dem vorgestellen Vorgehen und Werkzeugen ist es uns, ein recht elegantes Deployment unserer BI-Solution auf entfernte Umgebungen vorzunehmen. Großer Vorteil dabei ist die Möglichkeit, weite Teile durch Batch-Dateien und Konfigurationen zu automatisieren und damit den Aufwand mehrmaliger Deployments zu merklich reduzieren.

 Ich möchte hier kurz beschreiben, wie es möglich ist, unter Verwendung der ReportServer Datenbank, die Ausführung der Abonnements einfach zu verwalten.

Die Grundidee

Die Reporting Services speichern ihre Abonnements in der zugehörigen DB(Standardname: ReportServer). Die Tabelle in der alle Abonnements aufgeführt sind nennt sich dbo.Subscriptions:

In dieser Tabelle gibt es eine Spalte mit dem Namen InactiveFlags. Bei einem aktiven Abo ist dieser Wert auf 0 gesetzt. Um das Abo zu deaktivieren muss dieser Wert auf 1 geändert werden.

Die Umsetzung

Zunächst benötigen wir noch einige Tabellen, um die Lesbarkeit zu erhöhen, indem wir die IDs durch die zugehörigen Namen für Bericht, Abonnement und Benutzer ersetzen:

 

Mit dem nachfolgendem SQL-Statement können wir die passenden Informationen auslesen:

SELECT
     s.[SubscriptionID]
     ,s.[Description]
             ,u.UserName
             ,c.Name as ReportName
             ,[InactiveFlags]
             ,rs.ScheduleID AS JobName
             ,rs.ReportAction
             ,[ExtensionSettings]
             ,[Locale]
             ,s.[ModifiedByID]
             ,s.[ModifiedDate]
             ,[LastStatus]
             ,[EventType]
             ,[MatchData]
             ,[LastRunTime]
             ,[Parameters]
             ,[DataSettings]
             ,[DeliveryExtension]
             ,[Version]
             ,[ReportZone]
             ,[OwnerID]
             ,[Report_OID]
FROM [ReportServer].[dbo].[Subscriptions] s
             inner join dbo.Users u on u.UserID = OwnerID
             inner join [dbo].[Catalog] c on s.Report_OID = c.ItemID
             inner join [dbo].[ReportSchedule] rs on s.SubscriptionID = rs.SubscriptionID

Abhängig von den Abonnements sollte die Abfrage in etwa das folgende Ergebnis liefern:

 

Mit den oben stehenden Informationen können wir jetzt einzelne Abonnements aktivieren bzw. deaktivieren.

Für die Deaktivierung kann folgende Query verwendet werden:

UPDATE Subscriptions set
[InactiveFlags] = 1
where
[SubscriptionID] = ‘929CDEE8-…’
END

Für die Aktivierung kann das gleiche Update-Statement verwendet werden, der Wert InactiveFlags muss jetzt nur auf 0 gesetzt werden.

Ausführung von Abonnements

Gelegentlich kommt es vor, dass ein Abonnement außerhalb der geplanten Zeiten durchgeführt werden soll.

Da die Ausführung der Abonnements über den SQL Server Agent gesteuert wird, haben wir die Möglichkeit die passenden Jobs von Hand zu starten. Dies kann im SQL Server Management Studio erfolgen.

Oder es können vordefinierte gespeicherte Prozeduren aus der msdb Datenbank verwendet werden.

EXEC msdb.dbo.sp_start_job ‚251601B4…’


Die IDs der für die angelegten Jobs und die IDs für die zugehörigen Abos sind in der [dbo].[ReportSchedule] Tabelle der ReportServer DB hinterlegt. Wenn man diese Tabelle noch mit der dbo.Subscriptions verbindet:

SELECT
   [ScheduleID]
  ,[ReportID]
  ,rs.[SubscriptionID]
  ,s.Description
  ,[ReportAction]
FROM [dbo].[ReportSchedule] rs
INNER JOIN dbo.Subscriptions s ON rs.SubscriptionID = s.SubscriptionID

können die JobIDs den zugehörigen Abos zugeordnet werden.

Der passende Bericht

Nachdem die Grundlagen für die Deaktivierung bzw. Aktivierung der Abonnements geklärt sind, kann ein einfacher Bericht erstellt werden, mit dem die Ausführung und der Status des Abos gesteuert werden kann.

Für den Bericht muss eine Datenquelle für die ReportServer Datenbank erstellt werden und die folgenden Parameter werden benötigt, um die zugehörigen Funktionalitäten zu gewährleisten:

Des Weiteren brauchen wir ein Dataset, das zum einen die Informationen, wie vorhandene Abos, Berichtsnamen, etc. ermittelt, um sie im Bericht anzuzeigen, zum anderen aber auch Abos aktiviert und deaktiviert, sowie einzelne Jobs ausführt. Die Steuerung der Ausführung wird durch die einzelnen Parameter vollzogen und einzelne Teile der Abfrage übergangen oder ausgeführt:

if @SetActiv = 1
BEGIN
UPDATE Subscriptions set [InactiveFlags] = @InactiveFlags
where
    [SubscriptionID] = @id
END

if @Execute = 1
BEGIN
EXEC msdb.dbo.sp_start_job @JobName
WAITFOR
delay ‘00:00:05′
END

SELECT s.SubscriptionID, rs.ScheduleID AS JobName, s.OwnerID, u.UserName, s.Report_OID, c.Name AS Reportname, s.Description AS SubDesc, s.InactiveFlags AS Active, s.ExtensionSettings, s.Locale, s.ModifiedByID, s.ModifiedDate, s.LastStatus, s.EventType, s.MatchData, s.LastRunTime, s.Parameters, s.DataSettings, s.DeliveryExtension, s.Version, s.ReportZone
FROM Subscriptions AS s
   INNER JOIN Users AS u ON u.UserID = s.OwnerID
   INNER JOIN Catalog AS c ON s.Report_OID = c.ItemID
   INNER JOIN ReportSchedule AS rs ON s.SubscriptionID = rs.SubscriptionID


Im unteren Teil der Abfrage werden die Informationen ermittelt, im oberen Teil wird zunächst der Status des Abos aktualisiert oder der ausgewählte Job gestartet. Dadurch, dass das Statusänderungen und Jobausführungen über die Links in der Tabelle gesteuert werden, ist immer nur einer der beiden Parameter @SetActiv und @Execute eins und es wird immer nur eine der beiden Aktionen ausgeführt.

Um die Daten anzuzeigen erstellen wir eine einfache Tabelle:


Für das Feld Aktiv wird die folgende Expression: =iif(Fields!Active.Value = 0,“Aktiv”,“Deaktiviert”) verwendet und die folgende Aktion, für die Änderung des Status, definiert:


Zum Schluss muss noch das Ausführen des Jobs ermöglicht werden. Hierfür definieren wir eine Aktion für das Textfeld Execute:

Jetzt ist der Bericht soweit fertig, dass der Status und das Ausführen der Abos verwaltet werden kann, birgt aber noch die ein oder andere Gefahr in sich. So wird z.B. ein Abo erneut ausgeführt, wenn man den Bericht nach einem Execute aktualisiert. Für eine erste Demonstration sollte er aber reichen.

Dabei ging es um einen Cube, bei dem für ein bestimmtes Measure die Leerzeilenunterdrückung nicht so richtig funktionierte. Wenn man dieses Measure, das eigentlich eher selten gefüllt war, abfragte, dann sah das in etwa so aus:

Wie in diesem aus der Adventure Works stammenden Beispiel (wir sehen hier den Reseller Sales Discount Amount nach Reseller Telefonnummer) wurden die leeren Zellen mit einer 0 angezeigt, was ja bekanntlich nicht leer ist und somit auch nicht unterdrückt werden kann. Bei kurzem Blick in die Quelle fand ich in etwa folgendes Bild:

War also alles korrekt, was die Analysis Services so angezeigt haben. Der verwunderliche Teil der Geschichte beginnt aber auch erst jetzt.

Da es für Measures, bei denen mich die 0en gar nicht interessieren, nur bedingt Sinn macht, diese in der Datenbank abzulegen, habe ich also die Definition der Tabelle so geändert, dass die betroffene Spalte ab sofort NULL-Werte erlaubt. Danach wurden dann noch mit einem kleinen Statement wie unten die 0en eliminiert.