Pergunta

Eu estou tentando fazer nossos pacotes do SQL Server Integration Services tão portátil quanto possível e a única coisa que está impedindo que é que o caminho para a configuração é sempre um caminho absoluto, o que faz testes e implantação de uma dor de cabeça. Existem quaisquer sugestões para tornar isso mais manageble?

Outra questão é quando um outro desenvolvedor recebe o pacote de controle de origem do caminho é específico para a máquina de desenvolvedores.

Foi útil?

Solução

Se você está tentando executar seus pacotes usando Visual Studio, em seguida, o caminho do arquivo de configuração será codificado lá. Então, se você mover seu projeto em torno de você terá que alterar o caminho nas configurações do pacote. Para evitar isso, você pode usar a opção de variável de ambiente para armazenar o caminho do arquivo de configuração. Então você só precisa mudar isso.

para teste e implementação, contudo, você provavelmente deve usar o utilitário dtexec para executar seus pacotes. Faça alguns arquivos de lote para isso. De preferência, um para cada ambiente diferente. Aqui o caminho do arquivo de configuração pode ser relativo.

dtexec /File Package.dtsx /Conf configuration.dtsConfig"

Este é se você estiver pacotes estão no sistema de arquivos. Você também pode armazená-los em SQL Server. Você também pode armazenar sua configuração no SQL Server que pode proporcionar flexibilidade.

Outras dicas

Depois de várias horas tentando fazer este trabalho eu encontrei uma solução aqui (não o melhor, mas funciona)

  1. Localize seus arquivos de configuração (arquivos dtsconfig) no mesmo diretório que o seu arquivo de solução (ficheiro.SLN)
  2. sempre aberto sua solução (ficheiro.SLN) clicando duas vezes no arquivo de solução. Isto irá definir o ‘pasta de trabalho’ para ser o lugar onde as vidas de soluções, seu arquivo de configuração será lida corretamente

Caso contrário, os caminhos relativos não funcionou para mim.

Confira o utilitário gratuito que caminhos de arquivo pode editar a configuração SSIS sem lances: http://ssisconfigeditor.codeplex.com/

Meu estoque truque padrão para estes tipos de problemas são unidades de mapeamento.

De qualquer usando um rede mapeada unidade ou usando Subst (ambos os métodos são intercambiáveis).

por exemplo. Mapear a localização do seu pacote para N: \, em seguida, dentro de seus caminhos usar o pacote usando N: \ MyParentPackage.dtsx, N: \ MyChildPackage.dtsx. Os pacotes podem ser sobre totalmente diferentes unidades em pastas diferentes em máquinas diferentes, ele vai trabalhar uma vez que você mapear a localização pacote para o N: \

Eu costumo colocar um script ao lado dos arquivos de projeto para mapear a unidade, que mapeia a unidade para que possa ser facilmente executado antes. Uma pegadinha, se você estiver usando subst na VISTA -. Win8, mapeá-lo para elevado e não elevado

Eu uso a mesma abordagem para referências de arquivos em projetos do Visual Studio. Único problema com essa abordagem, você pode usar para resolver muitas questões em seu ambiente de dev e você vai ficar sem discos letras.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top