| Ungewöhnliche Eingabestrukturen für
SSIS Es gibt Datenstrukturen, bei denen die eingebauten Methoden von SSIS versagen. Wenn zum Beispiel folgende Daten eingelesen werden müssen, dann funktioniert das mit den Standardmethoden von SSIS nicht.
Mit DTS vom SQL Server 2000 konnte diese Datenstruktur ohne Problem eingelesen werden. Dieses Verhalten ist kein Bug, sondern wurde von den Entwicklern von SSIS ganz bewusst so gewählt. Die Begründung ist, wie könnte es anders sein, die Geschwindigkeit. Zugegeben, diese Struktur ist nicht wirklich Standard, aber so ungewöhnlich ist so auch nicht. Aber es gibt natürlich einen Weg, wie auch diese Daten mit SSIS eingelesen werden können. Selbstverständlich werden diese Daten mit dem Connection Manager für Flat Files eingelesen. Der erste Ansatz besteht darin, dass wir als Spaltentrennzeichen das Tabulatorenzeichen verwenden. Leider funktioniert das nicht wie gewünscht.
Als nächster Ansatz wird das Format Ragged right verwendet.
Beim Format für Flatfiles stehen folgende drei Möglichkeiten zur Verfügung:
Das spezielle Dateiformat wird mit dem Format Ragged right in eine einzige Spalte eingelesen. Standardmäßig ist jede Textspalte 50 Zeichen lang. Deshalb muss die Zeilenbreite manuell auf einen vernünftigen Wert gesetzt werden. Eine Textspalte kann eine Länge zwischen einem und 8000 Zeilen haben. Wird Unicode verwendet ist die maximale Länge 4000 Zeilen. Das Ergebnis überzeugt. Die Daten werden vollständig in die Pipeline eingelesen.
Jetzt geht es darum, diese eine Spalte in die echten Spalten aufzubrechen. Dafür ist der Einsatz der Script Komponente notwendig. Diese Transformation wird für jede Zeile im Datenstrom ausgeführt.
Bevor die Script Komponente geschrieben werden kann, muss immer die Struktur des Ausgabedatenstroms definiert werden. Falls es notwendig ist, können beliebig viele Ausgabedatenströme definiert werden.
Die Daten werden synchron, das heißt der gleiche Datenpuffer wird für die Ein- und Ausgabe verwendet, verarbeitet. Dieser Verarbeitungsmodus ist der effektivste. Da in der ersten Zeile die Spaltenüberschriften im Datenstrom vorhanden sind, wird diese im Code überlesen. Alle anderen Zeilen werden über das Trennzeichen in einzelne Werte zerlegt. Jeder dieser einzelnen Werte wird dann der entsprechende Spalte zugeordnet. Die Script Task oder die Script Komponente unterstützt als Scriptsprache ausschließlich VB.Net. Die anderen .Net Sprachen sind außen vor. Allerdings können auch Assemblies, die in jeder beliebigen .Net Sprache erstellt wurden, in dieser Task bzw. Transformation verwendet werden. Noch ein Punkt, der in dieser Version von SSIS etwas hinderlich ist:
Hier ist der Code für die Script Komponente aus dem Beispielpaket. Die erste Zeile, die die Spaltenüberschriften beinhaltet, wird für die weitere Verarbeitung gar nicht gebraucht. Es gibt aber keine Methode, diese Zeile in der Ausgabe zu unterdrücken. An dieser Stelle kommt die Conditional Split Transformation zum zug. Mit dieser Transformation kann der Datenstrom nach beliebigen Kriterien aufgeteilt werden. In dieser Transformation werden alle Zeilen, im Beispiel nur die erste, bei denen der Inhalt der Spalte Feld1 NULL ist in den Datenstrom mit dem Namen "Müll" umgeleitet. Dieser Datenstrom wird nicht weiterverarbeitet und versickert einfach. Der Inhalt der ersten Spalte bleibt auch erhalten. SSIS erkennt allerdings, wenn eine Spalte nach der Transformation nicht mehr benötigt wird und spart dann auch hier Ressourcen ein.
Der gesamte Dataflow sieht so aus.
Das Ziel ist in diesem Beispiel die universelle "Trash Destination". Die Performance dieses Verfahrens ist sehr gut, da das VB.NET Script immer kompiliert ausgeführt wird. Durch das kompilieren des Scriptcodes haben Sie keine Nachteile, außer das das SSIS Paket deutlich größer wird. Wird die 64 Bit Version von SSIS eingesetzt muss die Script Task oder Transformation immer kompiliert sein. Hier ist ein entsprechendes Beispiel einschließlich der notwendigen Eingabedatei.
Komponentenindex:
|