Faire quelques hypothèses ici, mais je vais supposer qu'il s'agit d'un problème 32 vs 64 bits. Pour vérifier, essayez ces deux commandes à partir d'une invite de commande (Touche Windows, R, cmd.exe ou Démarrer, Exécuter, 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
Le premier exécutera votre package en mode 32 bits tandis que le second l'exécutera en mode 64 bits. Cela aura de l'importance car vos pilotes et tous les DSN que vous avez créés ne seront visibles que dans le monde 32/64 bits.
Correction SSDT
Une fois que vous avez identifié celui dont vous avez besoin, probablement la version 32 bits, vous devez vous assurer que votre projet utilise le temps d'exécution approprié. Faites un clic droit sur votre projet et sélectionnez Propriétés, puis accédez à l'onglet Débogage sous les propriétés de configuration.
Après avoir inversé la valeur Run64BitRuntime, je suppose que votre package fonctionnera à partir de SSDT.
Correction de l'agent SQL
Vous devrez modifier le travail existant de l'Agent SQL pour changer le nombre de bits de l'étape du travail. Ce sera sous l'onglet Configuration, puis sous l'onglet Avancé. Cochez/décochez le runtime 32 bits.
Mensonges et tromperie
Les observateurs peuvent voir que le dtexec offre un /X86 option. Ne le croyez pas. La seule façon d'obtenir le nombre de bits correct est d'appeler explicitement le bon dtexec.exe. La documentation en dit même autant mais personne ne lit la documentation.
Cette option est uniquement utilisée par l'Agent SQL Server. Cette option est ignorée si vous exécutez l'utilitaire dtexec à l'invite de commande.
