Por padrão, tudo será executado em 64 bits nos servidores. Para alterar esse comportamento, você precisa indicar que a versão de 32 bits do dtexec deve ser usado. Para o SSISDB 2012, temos duas maneiras fáceis de invocar nossos pacotes:SQL Agent e o
catalog.start_execution método. catálogo.start_execution
Para execuções de pacotes de serviço único, você pode encontrar o pacote no catálogo do SSISDB e clicar com o botão direito neles para
Execute... Na caixa de diálogo pop-up resultante, você precisará ir para a guia Avançado e verificar o
32-bit runtime caixa. Isso seria feito em cada execução do pacote. 
Nos bastidores, o SQL gerado pelo assistente pareceria
DECLARE @execution_id bigint
EXEC [SSISDB].[catalog].[create_execution]
@package_name = N'Package.dtsx'
, @execution_id = @execution_id OUTPUT
, @folder_name = N'POC'
, @project_name = N'SSISConfigMixAndMatch'
, @use32bitruntime = True
, @reference_id = NULL
SELECT
@execution_id
DECLARE @var0 smallint = 1
EXEC [SSISDB].[catalog].[set_execution_parameter_value]
@execution_id
, @object_type = 50
, @parameter_name = N'LOGGING_LEVEL'
, @parameter_value = @var0
EXEC [SSISDB].[catalog].[start_execution]
@execution_id
GO
Como você pode ver, o
@use32bitruntime é passado um valor de True para indicar que deve ser executado em 32 espaços. Agente SQL
Para execuções de pacotes recorrentes, geralmente usamos uma ferramenta de agendamento. Para chegar à configuração de 32 bits para um pacote no agente, é basicamente o mesmo caminho de clique, exceto que primeiro você precisa clicar na guia Configuração e depois clique na guia Avançado para selecionar
32-bit runtime 
A definição da etapa de trabalho seria algo como
EXEC msdb.dbo.sp_add_jobstep
@job_name = N'Do it'
, @step_name = N'Run in 32bit'
, @step_id = 1
, @cmdexec_success_code = 0
, @on_success_action = 1
, @on_fail_action = 2
, @retry_attempts = 0
, @retry_interval = 0
, @os_run_priority = 0
, @subsystem = N'SSIS'
, @command = N'/ISSERVER "\"\SSISDB\POC\SSISConfigMixAndMatch\Package.dtsx\"" /SERVER "\".\dev2014\"" /X86 /Par "\"$ServerOption::LOGGING_LEVEL(Int16)\"";1 /Par "\"$ServerOption::SYNCHRONIZED(Boolean)\"";True /CALLERINFO SQLAGENT /REPORTING E'
, @database_name = N'master'
, @flags = 0
Você verá que na chamada @command, o assistente gera o
/X86 call que é o argumento especial reservado para o SQL Agent (verifique o link BOL no início) para indicar se a versão de 32 ou 64 bits do dtexec deve ser usada. Uma invocação de linha de comando exigiria que usássemos explicitamente o dtexec correto. Por padrão, o dtexec de 64 bits será listado primeiro em seu ambiente PATH localizações dtexec de 64 bits
- C:\Arquivos de Programas\Microsoft SQL Server\90\DTS\Binn\DTExec.exe
- C:\Arquivos de Programas\Microsoft SQL Server\100\DTS\Binn\DTExec.exe
- C:\Arquivos de Programas\Microsoft SQL Server\110\DTS\Binn\DTExec.exe
- C:\Arquivos de Programas\Microsoft SQL Server\120\DTS\Binn\DTExec.exe
localizações dtexec de 32 bits
- C:\Program Files (x86)\Microsoft SQL Server\90\DTS\Binn\DTExec.exe
- C:\Program Files (x86)\Microsoft SQL Server\100\DTS\Binn\DTExec.exe
- C:\Program Files (x86)\Microsoft SQL Server\110\DTS\Binn\DTExec.exe
- C:\Program Files (x86)\Microsoft SQL Server\120\DTS\Binn\DTExec.exe
Outros drivers de solução de problemas
Ele roda em um servidor, não em outro.
Etapa 1 - verifique se você instalou os drivers. Bobo, óbvio, mas tem havido muitas perguntas em que as pessoas erroneamente pensaram que a implantação de um pacote SSIS/.ispac também implantaria todos os assemblies referenciados. Não é nuget, então não, todos os pré-requisitos precisariam ser instalados e instalados corretamente (visto pessoas tentando copiar assemblies para o GAC em vez de usar a ferramenta)
Etapa 2 - verifique se a instalação do driver corresponde aos servidores. Novamente, parece óbvio, mas experimentei dor, geralmente VS_NEEDSNEWMETADATA, em uma diferença pontual na versão do driver 4.0.2.013 produziu resultados diferentes do 4.0.2.014
Etapa 3 - Certifique-se de que todos os DSNs que você definiu foram definidos no espaço correto. Este morde as pessoas por uma série de razões. Acho que não foi até o Server 2012 que você só conseguiu chegar à versão de 32 bits do odbcad32.exe (executável relacionado a Ferramentas Administrativas -> Fontes de Dados (ODBC)) foi encontrando-o no sistema de arquivos. Ainda mais confuso é que o executável é chamado odbcad32.exe, independentemente de estar em System32 ou SysWOW64 e essas duas pastas são para os drivers de 64 bits e drivers de 32 bits, respectivamente. Sim, futuros leitores, isso não é um erro de digitação. A versão 64 dos aplicativos está no System32, as versões de 32 bits estão no SysWOW64. Foi uma decisão de design destinada a minimizar o impacto.
No servidor de teste e ativo, execute
C:\Windows\SysWOW64\odbcad32.exe Encontre seus drivers FoxPro e os DSNs relacionados, eles estão conforme o esperado? Etapa 4 - Verificação de permissão estranha. Faça logon em ambos os servidores como uma conta "normal" e execute o pacote na linha de comando. Repita esta etapa, mas execute-a usando o Agent, com qualquer proxy que você possa ou não ter definido. Se o primeiro funcionar, mas o último falhar, isso geralmente indica um problema de permissão. Pode ser que a conta do SQL Server ou Agent não possa acessar a pasta em que o driver foi instalado. Pode ser que essa conta precise da permissão InteractWithDesktop ou alguma outra permissão negada ou não concedida explicitamente.
