Fazendo algumas suposições aqui, mas vou assumir que este é um problema de 32 vs 64 bits. Para verificar, tente estes dois comandos em um prompt de comando (Tecla Windows, R, cmd.exe ou Iniciar, Executar, 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
O primeiro executará seu pacote no modo de 32 bits, enquanto o segundo o executará no modo de 64 bits. Isso será importante, pois seus drivers e quaisquer DSNs que você criou serão visíveis apenas no mundo de 32/64 bits.
Corrigindo SSDT
Depois de identificar qual você precisa, provavelmente a versão de 32 bits, você precisa garantir que seu projeto esteja usando o tempo de execução apropriado. Clique com o botão direito do mouse em seu projeto e selecione Propriedades e navegue até a guia Depuração nas Propriedades de configuração.
Depois de inverter o valor Run64BitRuntime, presumo que seu pacote funcionará de dentro do SSDT.
Corrigindo o agente SQL
Você precisará editar o trabalho do SQL Agent existente para alterar o bittedness da etapa do trabalho. Isso estará na guia Configuração e, em seguida, na guia Avançado. Marque/desmarque o tempo de execução de 32 bits.
Mentiras e engano
Pessoas observadoras podem ver que o dtexec oferece um
/X86 opção. Não acredite. A única maneira de obter o bit-ness correto é chamar explicitamente o dtexec.exe correto. A documentação até diz isso, mas ninguém lê a documentação.
Essa opção é usada apenas pelo SQL Server Agent. Essa opção será ignorada se você executar o utilitário dtexec no prompt de comando.
