[firebase-br] rodar script no firebird

Tecnobyte Informática temp2 em tecnobyte.com.br
Qua Set 26 12:15:09 -03 2012


Bom dia

Faço praticamente a mesma coisa que você, mas tenho um único arquivo .dat 
(criado com ClientDataSet) que mantém uma lista com todos comandos que devem 
ser executados para atualizar o banco de dados, numerados pela versão do 
banco de dados.

Exemplo:

MeuScript.dat

1 - CREATE TABLE ...
2 - UPDATE ...
3 - CREATE SEQUENCE ...
4 - ALTER TABLE ADD ...
E por aí vai.

No banco de dados eu gravo o número da última atualização. Se, por exemplo, 
estiver gravado 2, então meu programa roda os comandos a partir do número 3, 
ou seja, roda estes comandos:

3 - CREATE SEQUENCE ...
4 - ALTER TABLE ADD ...
E por aí vai.

Eu optei por colocar os comandos SQL em um .dat porque nele eu gravo também 
um hash para garantir que ninguém vai modificar os comandos dentro do 
script. Se o hash não bater, o programa aborta a atualização com uma 
mensagem de arquivo inválido.

Atenciosamente.

Daniel P. Guimarães
Tecnobyte Informática
www.tecnobyte.com.br

-----Mensagem Original----- 
From: Gladiston Santana
Sent: Wednesday, September 26, 2012 10:04 AM
To: FireBase
Subject: Re: [firebase-br] rodar script no firebird

Eu uso a seguinte metodologia, tenho uma procedure chamada sp_version que
retorna o numero da versão do meu banco de dados.
Com isso em posse, eu crio executáveis para cada versão que autoexecutam o
script para qual estão programados, por exemplo, o setup da versão 256, só
é aplicável a base de dados com versão 255. Se o camarada pegou a versão
257 (ultima) e for tentar aplicar a atualização, o sistema negará.
Ou seja, para ter a base atualizadíssima, o camarada tem que executar a
atualização 255,256 e 257.
Parece meio burro, pois eu poderia criar um executável único, porém com
isso elimino a necessidade de testar um executável em todas as versões de
DB diferentes que andam rodando por aí.
Também há o caso, como já houve, de duplicar uma tabela, criar o
campo necessário e depois transferir de-lá-prá-cá, dropar a tabela antiga,
recriar a nova e transferir novamente. Com isso, cada executável é unico e
tem funcionado bem seguindo esse método que é meio ortodoxo.

Eu estava trabalhando num supersetup que cria uma base vazia e transfere
dados da antiga para nova, mas se tornou inviável quando fui descobrindo
aos poucos que tinha que descobrir as diferenças entras as tabelas e
assumir algum valor padrão para os campos não existentes, fui tentando
resolver os problemas, mas daí então a complexidade para automatizar a
tarefa foi aumentando até que cheguei a conclusão que o método que já
tínhamos era o melhor - embora ortodoxo - porque já tratava das situações
de uma versão para outra.

[]'s

Em 25 de setembro de 2012 21:19, MAURICIO COSTA
<maximmumsistemas em gmail.com>escreveu:

> Boa noite galera!
> Sempre atualizei meu sistema remotamente e indo até o cliente e criando os
> campos e tabelas novas e procedures etc.
> Gostaria de saber se posso colocar dentro de um instalador (atualizador) o
> script com as alterações no banco e o mesmo fazer isso no momento da
> atualização. Que ferramenta usar e como fazer?
> ______________________________________________
> FireBase-BR (www.firebase.com.br) - Hospedado em www.locador.com.br
> Para saber como gerenciar/excluir seu cadastro na lista, use:
> http://www.firebase.com.br/fb/artigo.php?id=1107
> Para consultar mensagens antigas: http://firebase.com.br/pesquisa
>
______________________________________________
FireBase-BR (www.firebase.com.br) - Hospedado em www.locador.com.br
Para saber como gerenciar/excluir seu cadastro na lista, use: 
http://www.firebase.com.br/fb/artigo.php?id=1107
Para consultar mensagens antigas: http://firebase.com.br/pesquisa 





Mais detalhes sobre a lista de discussão lista