Von: Koen Verbeeck | Updated: 2018-07-31 | Kommentare (13) | Verwandt: Mehr > Entwicklung von Integrationsdiensten

Problem

SQL Server Data Tools (SSDT) ist die Entwicklungsumgebung zum Erstellen und Pflegen von Integrationsdiensten (SSIS) Paketen und Projekten. In der Vergangenheit gab es keine Abwärtskompatibilität, was bedeutet, dass Sie mit einer neueren Version von SSDT keine SSIS-Pakete für eine ältere Version von SSDT erstellen konnten. Seit der Veröffentlichung von SQL Server 2016 unterstützt SQL Server Data Tools die Abwärtskompatibilität bis zu SQL Server 2012. Dieser Tipp erklärt die neue Funktion.

Lösung

Einführung

Historisch gesehen gab es zu jeder Version von SQL Server eine begleitende Version einer Business-Intelligence-Entwicklungsumgebung. Dabei handelte es sich immer entweder um eine Reihe von Vorlagen, die in Visual Studio installiert wurden, oder, falls Visual Studio noch nicht vorhanden war, um eine Shell von Visual Studio, die nur BI-Projekte verarbeiten konnte. Mit diesem Tool konnten Sie Integration Services-, Analysis Services- und Reporting Services-Projekte entwickeln. Ursprünglich hieß dieses Tool Business Intelligence Development Studio oder BIDS. In SQL Server 2012 wurde es in SQL Server Data Tools umbenannt. Microsofthatte jedoch auch ein anderes Produkt mit dem Namen SQL Server Data Tools; mit diesem Tool konnten Sie SQL Server-Datenbankprojekte erstellen und verwalten. Das BI-Tool war auf demSQL Server-Installationsmedium verfügbar, während das Datenbank-Tool ein separater (und kostenloser) Download war. Da dies zu einiger Verwirrung führte, wurde SSDT in SQL ServerData Tools for Business Intelligence oder SSDT-BI umbenannt. Seit SQL Server 2016 sind die BI-Tools nun mit dem Datenbank-Tool gekoppelt und das gesamte Toolset heißt nunSQL Server Data Tools oder SSDT. Ein Überblick:

• SQL Server 2005 – Visual Studio 2005 (BIDS)
• SQL Server 2008 und 2008R2 – Visual Studio 2008 (BIDS)
• SQL Server 2012 – Visual Studio 2010 (SSDT, auf SQL Server-Installationsmedien verfügbar) oder Visual Studio 2012 (SSDT-BI, als separater Download verfügbar)
• SQL Server 2014 – Visual Studio 2013 (SSDT-BI, verfügbar als separater Download)
• SQL Server 2016 – Visual Studio 2015 (SSDT, verfügbar als separater Download und beinhaltet auch Datenbankprojekte)
• SQL Server 2017 – Visual Studio 2015 oder Visual Studio 2017 (SSDT)

Das Problem hierbei war, dass SSIS keine Unterstützung für Abwärtskompatibilität hatte.Wenn Sie zum Beispiel Pakete für SQL Server 2008 entwickeln wollten, benötigten Sie VisualStudio 2008. Wenn Sie für SQL Server 2014 entwickeln wollten, brauchten Sie Visual Studio 2013. Mit Visual Studio 2013 konnten Sie keine SSIS-Projekte für SQL Server2008 oder eine andere Version von SQL Server entwickeln, außer für SQL Server 2014. Das bedeutete, dass Sie, wenn Sie mit mehreren Versionen von SSIS arbeiteten, viele verschiedene Versionen von Visual Studio auf Ihrem Entwicklungsrechner hatten.

Die neuesten Versionen von SSDT (seit SQL Server 2016) lösen diese Probleme: Durch die Einführung von Rückwärtskompatibilität können Sie eine einzige Version von SSDT verwenden, um Versionen von SSIS-Projekten von 2012 bis 2017 und später zu entwickeln und zu pflegen. Es ist wichtig zu erwähnen, dass SSAS und SSRS bereits seit einiger Zeit Abwärtskompatibilität unterstützen.

SSIS und Abwärtskompatibilität

Der Rest dieses Tipps wurde unter Verwendung der Visual Studio 2015 SSDT-Version zusammen mit SQL Server 2016 geschrieben. Alle Ratschläge, die in diesem Tipp gegeben werden, sind auch für spätere Versionen gültig.

Zunächst müssen wir die neueste Version der Visual Studio 2015SSDT-Vorschauversion installieren. Wenn Sie das Installationsmedium von SQL Server 2016 öffnen, finden Sie einen Link zur Download-Seite. Dort ist auch ein Link zur Downloadseite von SQL Server Management Studio (SSMS) enthalten, da dieses nun auch separat heruntergeladen werden kann.

Erstellen eines neuen Projekts

Wenn Sie ein neues Projekt hinzufügen, können Sie sehen, dass es nun möglich ist, in SSDT auch Datenbankprojekte und BI-Projekte zu erstellen.

In den Projekteigenschaften können Sie die SSIS-Zielversion einstellen, die SSDT für dieses Projekt verwenden wird.

Die Standard-Zielversion ist SQL Server 2016 (in späteren Versionen von SSIS wird das die neueste Version von SQL Server sein). SQL Server 2014 und SQL Server 2012 werden ebenfalls unterstützt, während ältere Versionen (2005 und 2008) nicht unterstützt werden. Wenn Sie ältere Projekte als SQL Server 2012 haben, müssen Sie diese zuerst aktualisieren, bevor Sie die neueste SSDT-Version verwenden können.

Wenn die Zielversion festgelegt ist, wird die SSIS-Toolbox entsprechend angepasst. Zum Beispiel gibt es in SQL Server 2016 neue Hadoop-Aufgaben und Sie können Azure-Aufgaben aus dem Azure-Feature-Pack herunterladen.

Wenn Sie die Version auf SQL Server 2014 einstellen, werden alle diese neuen Aufgaben aus der SSIS-Toolbox verschwinden. Das Gleiche gilt für Datenflusstransformationen, die in SQL Server 2016 eingeführt wurden.

Wenn Sie die Version eines Projekts ändern, erhalten Sie eine Warnung, dass bestehende Pakete möglicherweise geändert werden:

Wenn Sie jedoch die SQL Server 2016-Funktionalität verwenden, erhalten Sie nach dem Einstellen der Zielversion auf eine frühere Version beim Öffnen des Pakets einen Fehler:

Das Paket wird zwar geöffnet, aber die fehlerhaften Tasks, Transformationen oder Verbindungsmanager verschwinden möglicherweise, oder Sie können keinen Editor öffnen. Es ist möglich, dass der Wechsel zurück zu SQL Server 2016 das Problem nicht löst: Das Objekt könnte immer noch defekt sein. In diesem Fall gibt es keine andere Möglichkeit, als das Objekt zu entfernen und es erneut hinzuzufügen.

Zum Zeitpunkt der Erstellung dieses Artikels gibt es einige Fehler beim Wechsel zwischen Zielversionen. Eine Liste finden Sie im MSDN-BlogbeitragWhat’s New for SSIS 2016 RC0? Es ist möglich, dass einige dieser Fehler bereits behoben sind, wenn Sie dies lesen.

Wenn Sie Ihre eigenen benutzerdefinierten Komponenten in SSIS haben, müssen Sie einige zusätzliche Schritte unternehmen, damit sie mit der Eigenschaft Zielversion funktionieren. SQL Server MVP Joost vanRossum erklärt in seinem BlogbeitragSwitching Target Server Versions for custom components, wie Sie dies tun können.

Hinzufügen von vorhandenen Paketen zum Projekt

Wenn Sie ein vorhandenes SSIS-Paket aus einer früheren Version zum Projekt hinzufügen – zum Beispiel ein SSIS 2012-Paket zu einem 2016-Projekt – wird das Paket aktualisiert, um der Zielversion zu entsprechen.

Wenn die Versionen übereinstimmen, findet natürlich kein Upgrade statt, das Paket wird direkt zum Projekt hinzugefügt. Sie können auch Pakete aus einer höheren Version zum Projekt hinzufügen, SSIS wird versuchen, ein Downgrade durchzuführen.

Tests zeigen jedoch, dass man dieser Meldung nicht immer trauen kann. Selbst bei einer Erfolgsmeldung kann das Paket kaputt sein, wenn Sie nur SQL Server 2016-Komponenten verwenden.

Öffnen eines vorhandenen Projekts

Wenn Sie SSDT 2015 verwenden, um ein Projekt zu öffnen, das mit einer früheren Version von SSDT erstellt wurde, wird der Upgrade-Assistent automatisch gestartet. Das bedeutet, dass alle Pakete auf SQL Server 2016 aktualisiert werden.

Obwohl Sie das Projekt immer noch auf die frühere Version zurückstufen können, möchten Sie den Upgrade-Prozess vielleicht nicht durchlaufen. Als Alternative können Sie die Projektdatei bearbeiten und die folgende Zeile hinzufügen:

Dadurch überspringt SSDT 2015 den Upgrade-Assistenten und öffnet das Projekt direkt mit der richtigen Zielversion. Für SQL Server 2014 ändern Sie natürlich SQLServer2012in SQLServer2014. Obwohl diese Lösung zu funktionieren scheint, wird die manuelle Bearbeitung des XML der Projektdatei nicht wirklich unterstützt. Mein Rat ist, ein neues leeres Projekt zu erstellen, die Zielversion festzulegen und dann mit dem Hinzufügen von Paketen zu beginnen.

Steuerungsablaufteile

Steuerungsablaufteile werden im TippSQL Server Integration Services 2016 Control Flow Templates Introduction vorgestellt (sie wurden von Vorlagen in Teile umbenannt). Überraschenderweise können Sie auch mit Kontrollfluss-Teilen arbeiten, wenn Ihre Zielversion nicht SQL Server2016 ist. Dies ist möglich, weil sie eine Funktion zur Entwurfszeit sind und keinen Einfluss darauf haben, wie Pakete tatsächlich funktionieren. In diesem Beispiel habe ich ein neues Projekt erstellt, dessen Zielversion auf SQL Server 2014 eingestellt ist. Ich habe einen einfachen Kontrollfluss-Teil erstellt und dem Paket hinzugefügt.

Das Debuggen des Pakets ist kein Problem.

Und Sie können das Paket auch innerhalb eines SQL Server 2014 SSIS-Katalogs ausführen:

Abschluss

Die Eigenschaft „Target Server Version“ führt Abwärtskompatibilität für SSIS-Projekte in SSDT 2015 ein. Mit dieser neuen Fähigkeit wurde ein altes Problem von SSIS endlich behoben: Sie können nur eine einzige Version von Visual Studio verwenden, um Ihre verschiedenen SSIS-Projekte zu verwalten. Es wird empfohlen, die Serverversion zu Beginn des Projekts festzulegen und nicht zu oft zu wechseln, da dies zu Problemen führen kann.

Nächste Schritte

• Für weitere Informationen zu den verschiedenen Versionen von SQL Server Data Tools:
  • DieSSDT Evolution
  • SQL 2014 CTP1, wo ist mein BIDS?
• Weitere Informationen zu Kontrollfluss-Teilen finden Sie im TippSQL Server Integration Services 2016 Control Flow Templates Introduction.
• Weitere Tipps zu SQL Server 2016 finden Sie in dieser Übersicht.

Last Updated: 2018-07-31

Über den Autor

Koen Verbeeck ist ein BI-Profi, der sich auf den Microsoft BI-Stack spezialisiert hat, mit einer besonderen Liebe für SSIS.
Alle meine Tipps ansehen

Verwandte Ressourcen

• Mehr Business Intelligence Tipps…