none
Execução de pacote SSIS com conexão Oracle via JOB gera erro, o qual não ocorre no Visual Studio RRS feed

  • Discussão Geral

  • Pessoal, bom dia!

    Tenho um pacote SSIS que foi criado com uma conexão Oracle, usando o provider OraOLEDB.Oracle, que, ao executar no visual studio em modo designer, funciona sem problemas. O ambiente é um SQL Server 2005 x86 (SSIS x86).

    Ao levar o pacote para a produção, ou seja, um SQL Server 2005 X64 (SSIS x64), importei o pacote DTSX em um JOB, e, tanto por linha de comando... ("C:\Program Files (x86)\Microsoft SQL Server\90\DTS\Binn\DTExec.exe" /FILE "C:\SSIS\pack_name.dtsx"  /DECRYPT "password" /MAXCONCURRENT " -1 " /CHECKPOINTING OFF)), ou importando na base MSDB, ocorre o erro abaixo:

    Message
    Executed as user: DOMAIN\User. ...9.00.4035.00 for 64-bit  Copyright (C) Microsoft Corp 1984-2005. All rights reserved.    Started:  09:51:39  Error: 2012-12-12 09:51:40.85     Code: 0xC02020F6     Source: Atualiza LctosCtb Sapiens [1]     Description: Column "CENTROCUSTO" cannot convert between unicode and non-unicode string data types.  End Error  Error: 2012-12-12 09:51:40.85     Code: 0xC02020F6     Source: Atualiza LctosCtb Sapiens [1]     Description: Column "HIST" cannot convert between unicode and non-unicode string data types.  End Error  Error: 2012-12-12 09:51:40.90     Code: 0xC004706B     Source: Atualiza LctosCtb DTS.Pipeline     Description: "component "Sapiens" (1)" failed validation and returned validation status "VS_ISBROKEN".  End Error  Error: 2012-12-12 09:51:40.90     Code: 0xC004700C     Source: Atualiza LctosCtb DTS.Pipeline     Description: One or more component failed validation.  End Error  Error: 2012-12-12 09:51:40.90     ...  The package execution fa...  The step failed.

    O fato curioso é que o pacote não acusa erros, quando aberto e quando gero um BUILD. Inclusive ele roda sem erros.

    Este erro ocorre numa task que tem uma conexão Oracle, a qual citei acima.

    OBS: Tentei usar o provider MSDAORA, mas não existe para ambientes x64, então descartei.

    Qualquer ajuda, será bem vinda.

    quarta-feira, 12 de dezembro de 2012 13:33

Todas as Respostas

  • Coronel,

    Você recompilou o package no SSIS em ambiente x64?

    Existe uma opção que você pode configurar nas propriedades do package para informar a plataforma do ambiente.


    Pedro Antonio Galvão Junior [MVP | Microsoft Evangelist | Microsoft Partner | Engenheiro de Softwares | Especialista em Banco de Dados | SorBR.Net | Professor Universitário | MSIT.com]

    quarta-feira, 12 de dezembro de 2012 18:27
    Moderador
  • Já agora como importar um pacote ou vários pacotes SSIS para um servidor de produção. Sem perder as conexões?

    Não compreendo bem isso!!

    sexta-feira, 14 de dezembro de 2012 16:38
  • Coronel, como deve estar executando um ambiente de 64 Bits, mesmo rodando sua package importada no MSDB, a mesma base está sendo executada em ambiente 64.

    Desta forma, não tem muito como fugir.

    Mesmo você instalando o Oracle.DataAccess (ODP.Net) na versão 64 Bits, ela acaba não aparecendo na lista suspensas de providers a serem escolhidos (pode até aparecer, mas na versão 32 Bits).

    Como está em ambiente de Produção, alterar a configuração do servidor é considerado loucura, porém, ao instalar o Oracle.DataAccess (ODP.Net), você também instala sua versão 32 Bits.

    Resumindo, já pensou em trocar a configuração do seu projeto para rodar em 32 Bits?

    Procure simular o seu ambiente em um servidor virtualizado para ver o resultado.


    Cristiano Joaquim

    sexta-feira, 14 de dezembro de 2012 21:27
  • Olá pessoal,

    Respondendo a pergunta do Galvão, não recompilei no ambiente x64 ainda.

    Meu ambiente de desenvolvimento é 32-bits, daí o problema. Se a produção fosse 32-bits tb, o problema estaria resolvido, pois poderia utilizar sem problemas o provider MSDAORA, no qual o pacote foi criado.

    Cristiano, obrigado pelas dicas. Sim, me ocorreu de utilizar um server com Integration Services em 32-bits, aí soluciona.

    Sobre os erros de conversões (Column "HIST" cannot convert between unicode and non-unicode string data types.), consegui contornar da seguinte forma:

    Dentro do Visual Studio, em Package Explorer, Executables, depois Components, alterada a opção ValidadeExternalMetadata para FALSE.

    Gerei novo BUILD e importei o pacote DTSX para dentro da base MSDB. Execução realizada com sucesso via JOB.

    Apenas não entendi porque deixando de validar os metadados, pelo server x64 ele acusa erro... e pelo desenv não!

    De qualquer forma, obrigado a todos!

    Coronel Jesuíno!

    segunda-feira, 17 de dezembro de 2012 11:46