Ich mache hier einige Annahmen, aber ich gehe davon aus, dass dies ein 32-gegen-64-Bit-Problem ist. Probieren Sie zur Überprüfung diese beiden Befehle von einer Eingabeaufforderung aus (Windows-Taste, R, cmd.exe oder Start, Ausführen, cmd.exe)
"C:\Program Files (x86)\Microsoft SQL Server\110\DTS\Binn\dtexec.exe" /file C:\myPackage.dtsx
"C:\Program Files\Microsoft SQL Server\110\DTS\Binn\dtexec.exe" /file C:\myPackage.dtsx
Der erste führt Ihr Paket im 32-Bit-Modus aus, während der zweite es im 64-Bit-Modus ausführt. Dies spielt eine Rolle, da Ihre Treiber und alle von Ihnen erstellten DSNs nur in der 32/64-Bit-Welt sichtbar sind.
SSDT reparieren
Sobald Sie festgestellt haben, welche Sie benötigen, wahrscheinlich eine 32-Bit-Version, müssen Sie sicherstellen, dass Ihr Projekt die entsprechende Laufzeit verwendet. Klicken Sie mit der rechten Maustaste auf Ihr Projekt und wählen Sie Eigenschaften und navigieren Sie dann zur Registerkarte Debugging unter den Konfigurationseigenschaften.
Nach dem Invertieren des Run64BitRuntime-Werts gehe ich davon aus, dass Ihr Paket innerhalb von SSDT funktioniert.
SQL-Agent reparieren
Sie müssen den vorhandenen SQL Agent-Job bearbeiten, um die Bitterkeit des Jobschritts zu ändern. Dies befindet sich auf der Registerkarte Konfiguration und dann auf der Registerkarte Erweitert. Aktivieren/deaktivieren Sie die 32-Bit-Laufzeit.
Lügen und Täuschung
Aufmerksame Leute sehen vielleicht, dass dtexec einen /X86 anbietet Möglichkeit. Glauben Sie es nicht. Die einzige Möglichkeit, die richtige Bitanzahl zu erhalten, besteht darin, explizit die richtige dtexec.exe aufzurufen. Die Dokumentation sagt sogar so viel, aber niemand liest die Dokumentation.
Diese Option wird nur vom SQL Server-Agent verwendet. Diese Option wird ignoriert, wenn Sie das Dienstprogramm dtexec an der Eingabeaufforderung ausführen.
