Praxisbeispiel
Zur Veranschaulichung wird ein beispielhaftes Szenario in einem fiktiven Unternehmen durchgespielt. Man betrachte die folgende Ausgangssituation: Es wird ein Server (Windows Server 2016) mit einem SQL-Server 2016 betrieben, beides in der englischen Sprachversion. Ebenso auch alle anderen Komponenten, wie Visual Studio 2017 für die Verwaltung der SSIS-Pakete sowie der SSAS-Datenbanken.
Nun werden die regionalen Einstellungen des Servers (Datum, Dezimale, Tausendertrennzeichen, etc.) auf Deutsch umgestellt. In diversen SSIS-Paketen werden Daten mittels Datenflusstask aus einer AS400 importiert. Dies führt zu diversen Fehlermeldungen:
- DTS_E_PRIMEOUTPUTFAILED mit Fehler 0xC0202029
- DTS_E_INDUCEDTRANSFORMFAILUREONERROR mit Fehler 0x0209072
- The value could not be converted because a potential loss of data.
Fehlersuche
In Visual Studio ist alles problemlos durchgelaufen. Der Aufruf der Daten aus der AS400 erfolgt mittels OLE DB (IBM DB2 for i IBMDA400 OLE DB Provider), über den SQL-Server-Agent allerdings nicht. Dort wurden die Fehlermeldungen erzeugt. Im nächsten Schritt schaut man sich an, welchen Datentyp das ausgewiesene Fehlerfeld hat. In diesem Beispiel lautet er numeric(18,2), der Datentyp der Zielspalte ist ebenfalls numeric(18,2). Daraus ergeben sich folgende Fragen:
- Wieso kann der SQL-Server diesen Datentyp nicht richtig auslesen bzw. wieso in Visual Studio aber nicht im SQL-Server Agent?
- Warum betrifft das nur Felder mit Nachkommstellen?
Wir haben den Datenbank-Experten in unserem Haus gefragt, wie er in dieser Situation vorgehen würde. Er hat für uns einen Testdurchlauf gestartet.
„Zunächst würde ich für aufwendigere Fehlersuchen ein Test-SSIS anlegen und als Erstes den Quelltask über den erweiterten Editor unter die Lupe nehmen. Dort gibt es diverse Möglichkeiten, um spaltenweise Anpassungen vorzunehmen. Beispielhaft nehme ich die Spalte DWMENG, welche auch in der Fehlermeldung ausgewiesen ist. Hier ist zu beachten, dass alle Spalten mit numeric und Nachkommastellen angepasst werden müssen.“
„Es ist ebenso wichtig darauf zu achten, dass die Nachkommagenauigkeit auch gleichbleibt. Startet man anschließend einen Testdurchlauf, läuft der Job dann auch fehlerfrei durch. Allerdings stellt man fest, dass die Zahlen ohne Beachtung der Nachkommastellen übernommen wurden und die Daten daher nicht korrekt sind, obwohl sie in der Vorschau richtig angezeigt wurden.“
„Als Nächstes werden die Regionaleinstellungen von Deutsch auf Englisch zurückgestellt und nochmals getestet, ohne etwas im SSIS-Paket zu ändern. Wie erwartet stimmen die Zahlen nun. Also wird das Paket im Visual Studio in der englischen Regionaleinstellung wieder geöffnet, gespeichert und neu veröffentlicht. Nach einem erneuten Testdurchlauf wird dann alles einwandfrei und korrekt angezeigt. Wir stellen also fest, dass die AS400-Schnittstelle und der SQL-Server beim Umstellen der Regionaleinstellungen nicht mehr vernünftig mit den Nachkommastellen umgehen können.“
Lösungsweg
Als Lösungsansätze gibt es 2 Vorgehensweisen:
Möchte man weiterhin die Geschwindigkeit der OLE DB-Schnittstelle verwenden, müsste in den erweiterten Einstellungen die Ausgabespalte als „string [DT_STR]“ gekennzeichnet werden.
In der Abfrage auf die Quelltabelle muss man dann alle umgestellten Felder mit dem Befehl REPLACE an die Dezimalgegebenheit anpassen: REPLACE(COLUMN,',','.') AS Column.
Alternativ dazu, z. B. bei einer kleinen Anzahl an Datensätzen, kann anstatt des OLE DB-Connectors die ADO.Net-Schnittstelle eingesetzt werden. Diese ist vom Aufbau her ähnlich wie die OLE DB-Schnittstelle. Diese kann jedoch nur nvarchar-Felder, sodass man hier ein „Data Conversation“-Task einbauen müsste, da dort bisher nur varchar-Felder verwendet werden.
