No dia-a-dia do desenvolvimento, é comum precisarmos reproduzir uma determinada situação ocorrida no cliente. Só que precisamos dos dados exatos para isso!

Geralmente solicitamos SELECTs ou backups. Mas e quando não dá?

Em ambientes com restrições onde não é possível solicitar um backup e um SELECT não é suficiente, pois precisamos trabalhar com os dados e não apenas visualizá-los, existe uma alternativa prática para recuperar os dados do ambiente.

Script que gera INSERTs

Inicialmente desenvolvi um script para Oracle em PL/SQL para migração de dados entre ambientes. O resultado foi bom e fizemos também uma versão para SQL Server.

No caso do SQL Server trata-se de uma procedure que, quando executada, gera INSERTS a partir dos dados de uma tabela. Veja os exemplos abaixo:

-- Gera INSERTS para todos os registros da tabela TAB1
EXEC GET_INSERT_SCRIPT
    @TABELA = 'TAB1',
    @BANCO_ORIGEM = 'MINHA_BASE',
    @BANCO_DESTINO = DEFAULT,
    @OWNER = DEFAULT,
    @WHERE = DEFAULT,
    @GERAR_DELETE = 0

-- Gera INSERTs para todos os registros da tabela TAB2
EXEC GET_INSERT_SCRIPT
    @TABELA = 'TAB2',
    @GERAR_DELETE = 0

-- Gera INSERT para a tabela de produtos somente para o produto 'PROD' da empresa 'EMP1'
EXEC GET_INSERT_SCRIPT
    @TABELA = 'PRODUTOS',
    @WHERE = 'CODPRODUTO = ''PROD'' AND LECOLCOD = ''EMP1'' '

-- Gera INSERT da tabela BOLETOS somente para o boleto '123'
EXEC GET_INSERT_SCRIPT
    @TABELA = 'BOLETOS',
    @BANCO_ORIGEM = 'MINHA_BASE',
    @BANCO_DESTINO = DEFAULT,
    @OWNER = DEFAULT,
    @WHERE = 'CODBOLETO = 123'

Observações

No primeiro exemplo, é definido o banco de origem como  “MINHA_BASE”. Esse parâmetro é opcional, se o banco de dados já estiver selecionado (“USE”).

Os parâmetros com valor “DEFAULT” indicam que o SQL deve usar o valor padrão definido pela procedure. Eles poderiam ser simplesmente omitidos.

O parâmetro @GERAR_DELETE define se o script gerado vai conter também um comando “DELETE” para apagar os dados da tabela.

Os parâmetros @OWNER, @BANCO_ORIGEM e @BANCO_DESTINO podem ser omitidos e somente precisam ser usados se houver necessidade de executar os scripts a partir do master ou com um usuário cujo owner é diferente do owner  do banco de dados. O padrão para o @OWNER é “dbo”.

Caso esses parâmetros sejam informados, o caminho para os objetos será escrito como no exemplo:

AB_BANCO_DESTINO.dbo.TABELA

No segundo exemplo, o parâmetro @WHERE faz com que os dados gerados e o DELETE (se houver) contenham o filtro passado. Então também é possível criar uma carga parcial com o filtro desejado.

Somente é preciso tomar cuidado com a saída. O Management Studio limita a quantidade de texto retornado, então é recomendável alterar a configuração  Tools > Options > Query Results > SQL Server > Results to Text > Maximum number of characters... para o valor de “4000” ou simplesmente jogar a saída para um arquivo.

Vantagens

Armazenamento e migração de dados de forma transparente, sendo possível analisar e alterar os dados.

O desenvolvedor pode selecionar exatamente os registros que deseja. São poucas as ferramentas que permitem geração de scripts com filtro por registros.

Não é necessário que a pessoa que vai executá-lo saiba usar uma ferramenta de geração de scripts e tenha que selecionar as tabelas ou até registros manualmente.

Problemas

Tabelas com tipos de dados que não podem ser representados em texto.

Tabelas muitos grandes vão gerar scripts impossíveis de editar.

Versão para Oracle

A versão Oracle atual não tem todas as opções da versão SQL Server, mas já foi utilizada para migração de dados entre ambientes com sucesso.

Disponível em

https://github.com/utluiz/database-insert-script-generator

Dúvidas, sugestões, correções ou apontamento de erros são bem-vindos!