Facendo alcune ipotesi qui, ma suppongo che si tratti di un problema a 32 contro 64 bit. Per verificare, prova questi due comandi da un prompt dei comandi (tasto Windows, R, cmd.exe o Start, Esegui, 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
Il primo eseguirà il pacchetto in modalità a 32 bit mentre il secondo lo eseguirà in modalità a 64 bit. Questo avrà importanza poiché i tuoi driver e tutti i DSN che hai creato saranno visibili solo nel mondo a 32/64 bit.
Correzione SSDT
Una volta identificato quello di cui hai bisogno, probabilmente la versione a 32 bit, dovresti assicurarti che il tuo progetto stia utilizzando il runtime appropriato. Fare clic con il pulsante destro del mouse sul progetto e selezionare Proprietà, quindi passare alla scheda Debug in Proprietà di configurazione.
Dopo aver invertito il valore Run64BitRuntime, presumo che il tuo pacchetto funzionerà da SSDT.
Correzione dell'agente SQL
Sarà necessario modificare il processo di SQL Agent esistente per modificare il livello di bit del passaggio del processo. Questo sarà nella scheda Configurazione e quindi nella scheda Avanzate. Seleziona/Deseleziona il runtime a 32 bit.
Bugie e inganni
Gli attenti possono vedere che dtexec offre un /X86
opzione. Non crederci. L'unico modo per ottenere il bit-ness corretto è chiamare esplicitamente il dtexec.exe corretto. La documentazione dice anche tanto ma nessuno legge la documentazione.
Questa opzione viene utilizzata solo da SQL Server Agent. Questa opzione viene ignorata se si esegue l'utilità dtexec al prompt dei comandi.