Estou criando um conjunto de pacotes SSIS 2014 (usando o Visual Studio 2013) importando dados de 50 tabelas. Como a maioria das tabelas está sendo filtrada na mesma coluna e estou importando todas as colunas para minha área de preparação, optei por um design reutilizável onde meu nome de pacote corresponde ao nome da tabela, minha consulta de origem OLE DB é definida com uma expressão- variável baseada (começando com SELECT * FROM <tablename>...) e minha tabela de destino OLE DB também é definida com uma variável baseada em expressão (neste caso schema.tablename ).
Tanto a consulta de origem quanto a tabela de destino têm nomes de coluna correspondentes e correspondem na maioria dos casos em tipos e tamanhos de dados.
Conforme estou clonando meus pacotes para cada tabela, copio/colei um pacote criado anteriormente e inspeciono visualmente os mapeamentos para confirmar se as expressões e os mapeamentos de fluxo de dados são válidos para o novo nome de pacote. Estou vendo que as expressões estão funcionando conforme o planejado, mas tenho que fazer manualmente o mapeamento de arrastar/soltar da maioria das colunas no editor de destino.
Esse comportamento esperado do editor, pois os metadados de design do pacote original são inválidos sob o novo nome do pacote e existe uma maneira de fazer com que o Visual Studio exclua e remapeie todas as colunas no fluxo de dados com base no nome da coluna?
Copiar e colar pacotes SSIS pode levar a alguns problemas. Parece que você tem pacotes simples - um fluxo de dados com uma origem para o destino. Geralmente, eles não têm o problema que encontrei, mas já vi situações em que as pessoas eram inconsistentes em sua definição de tipos de dados. Email - varchar(40), varchar(80), varchar(120), nvarchar(256) todos no mesmo banco de dados, apenas em tabelas diferentes. O que pode acontecer é que você primeiro construa seu pacote usando o tamanho 80. Quando você copia/cola e corrige sua tabela de origem, o editor pode não captar a alteração do tamanho dos dados quando você vai para a tabela 40 porque ela se ajusta ao tamanho antigo. Mas também vi o contrário - pode não pegar o tamanho aumentado. A resolução não é horrível, basta alterar sua consulta para
select 1 AS x, deixe-o definir os metadados e, em seguida, corrija sua consulta de volta para a seleção adequada.Como sugeriu Dave, esta tarefa é ideal para uma tarefa Biml de nível básico. Na verdade, desde que você não se importe de não ter sua consulta de origem explícita, minha replicação-o-matic Biml é exatamente o que você está descrevendo. A encarnação anterior está no SO e estou vinculando-a para proteger contra a podridão do link.
Se você gosta de sua abordagem, você pode manter sua abordagem. Mas, poupe-se de clicar e arrastar em seu destino e substitua-o por seis cliques: três à direita, três à esquerda. Na guia de mapeamentos, clique com o botão direito para abrir este menu sensível ao contexto
Clique com o botão esquerdo em "Selecionar todos os mapeamentos"
Clique com o botão direito do mouse e clique com o botão esquerdo em "Excluir mapeamentos selecionados"
Clique com o botão direito e depois com o botão esquerdo em "Mapear itens por nomes correspondentes"
Sim, mesmo depois de resolver as referências, o destino não será mapeado automaticamente. Você deve criar um novo destino ou selecionar uma tabela diferente para o seu destino, aceitar/fechar, abrir e selecionar o destino pretendido e agora deve resolver automaticamente suas associações de coluna. Eu também tive dificuldade com isso antes.
Com 50 tabelas agora quem sabe quantas no futuro, você deve verificar o BIML que irá gerar o XML para cada pacote e assim (supondo que você configurou tudo corretamente) nem precisa inspecionar os pacotes criados.