Es gibt Aufgaben, bei denen man im Vorfeld denkt, damit bin ich ja in 2 Stunden durch. Und dann sitzt man den Rest des Tages haareraufend vor dem Rechner und zweifelt an sich selbst. Eine ähnlich schöne Zeit haben mir vor kurzem die Integration Services (2008 R2) beschert.

Aufgabe war es, ein bestehendes ETL-Paket für eine andere Datenquelle anzupassen, die sich nur in den Tabellen- und View-Namen, nicht aber in den verwendeten Spalten, von der ersten Quelle unterschied. Zur Nachvollziehbarkeit hier mal ein Beispiel auf der AdventureWorks-Datenbank, das ein paar Kundendaten von A nach B kopiert.

Normaler Datenfluss

Die einzelnen Datenflüsse wurden wie erwartet schnell auf die neue Quelle umgeändert, indem einfach der Tabellenname ausgetauscht wurde.

Parametrisierte Query nach Umbau

Hier wurde also z.B. die Tabelle dbo.DimCustomer auf eine gefilterte View vw_MeineCustomer umgestellt.

Nach Umbau aller Datenflüsse und Queries kam der Testlauf und tatsächlich lief das Paket auf Anhieb durch.

Datenfluss nach Umbau, ohne Daten

Aber halt, warum werden da gar keine Daten bewegt? Da werde ich wohl doch etwas falsch gemacht haben. Also die Abfrage direkt mit eingesetztem Parameter auf der Datenbank ausgeführt und siehe da, es kommen Daten zurück. Liegt es am Parameter? Gehe ich auf die falsche Datenbank? Sollte ich Gärtner werden?

Leicht frustriert guckte ich mir die Abfragen, die SSIS zur Datenbank schickte, im SQL Server Profiler an. Die eigentliche Abfrage sah auch hier völlig unauffällig aus, aber was passiert denn da ein Stück darüber?

Profiler Trace der generierten Abfragen

set

fmtonly on select [GeographyKey] from [dbo].[vw_MeineCustomer] –Achtung, gefiltert! where 1=2 set fmtonly off

Um die Metadaten des Parameters für GeographyKey zu ermitteln, führt SSIS die Abfrage in einem speziellen Modus aus, der ohne tatsächliche Datenabfrage die Datentypen der einzelnen Spalten zurückgibt. Dieser Modus wird mit SET FMTONLY ON initiiert und nach der Abfrage mit SET FMTONLY OFF wieder verlassen. Die Where-Clause der Query wird dabei abgeschnitten und durch 1=2 ersetzt.

Leider wird das ganze ohne Zeilenumbrüche generiert. Dadurch wird FMTONLY zwar an- aber nicht mehr abgeschaltet, da SET FMTONLY OFF durch den Kommentar hinter dem Namen der View nicht mehr ausgeführt wird.

Entfernen wir den Kommentar bzw. verwenden wir die alternative Syntax /*<Kommentar>*/,

Query mit geändertem Kommentar

dann fließen auch wieder die Daten.

Query ohne Kommentar, mit Daten

Die Kombination: Parameter in der OLEDB-Quelle und Kommentar hinter dem Tabellennamen, sorgt also dafür, dass keine Zeilen mehr durch den Datenfluss fließen.