Fórum Atualizar Estrutura Firebird Automatica #418906
25/06/2012
0
Pessoal Bom Dia,
Eestou trabalhando com o firebird e a nao sei como devo fazer para atualizar de forma automatica as estruturas das tabela nos clientes ou seja no ambiente de desemvolvimento eu crio novos campos e esses campos devem ser atualizados no firebird do cliente de forma automatica.
Qual é a melhor maneira de fazer esse processo.
Eestou trabalhando com o firebird e a nao sei como devo fazer para atualizar de forma automatica as estruturas das tabela nos clientes ou seja no ambiente de desemvolvimento eu crio novos campos e esses campos devem ser atualizados no firebird do cliente de forma automatica.
Qual é a melhor maneira de fazer esse processo.
Leandroptu
Curtir tópico
+ 0
Responder
Post mais votado
26/06/2012
Sugestão 1:
Implementar um dicionário de dados com identificação de versão.
Ter um campo na base de dados com a versão do sistema.
Ao rodar o seu atualizador ele irá validar a versão do banco de dados e executar as atualizações necessárias da versão gravada no banco de dados até a versão do seu executável.
Ponto positivo:
O dicionário de dados poderá ser utilizado para outras funcionalidades em todo o sistema.
Se futuramente resolver utilizar outro banco de dados, provavelmente não serão muitas as alterações.
Ponto negativo:
Sempre que necessitar atualizar o cliente deverá disponibilizar novo executável do programa atualizador.
Se utilizar procedures, triggers, etc, será necessário algum arquivo com o script com o conteúdo para realizar atualização, pode ser dll ou outro.
Sugestão 2:
Implementar um comparador de base de dados.
O atualizador deverá comparar a base de dados do cliente com uma base original com a estrutura atualizada (sem dados), e executar as alterações necessárias.
Ponto positivo:
Não é necessário enviar executável ao cliente a cada atualização de base de dados.
Não é necessário enviar arquivos auxiliares para procedures, triggers, etc.
Ponto negativo:
Sempre deverá enviar uma base de dados ou script para criar a base com a estrutura atualizada para ser comparada. Dependendo da estrutura da base de dados, a comparação poderá demorar mais que a sugestão 1.
Necessário conhecer muito bem a estrutura das tabelas do sistema do SGBD, se resolver trocar de banco de dados, provavelmente terá um trabalho maior.
Para os dois casos:
Se possível, sempre execute a atualização no servidor, é muito mais rápido.
Não esqueça do backup antes de atualizar.
Espero ter contribuído.
Implementar um dicionário de dados com identificação de versão.
Ter um campo na base de dados com a versão do sistema.
Ao rodar o seu atualizador ele irá validar a versão do banco de dados e executar as atualizações necessárias da versão gravada no banco de dados até a versão do seu executável.
Ponto positivo:
O dicionário de dados poderá ser utilizado para outras funcionalidades em todo o sistema.
Se futuramente resolver utilizar outro banco de dados, provavelmente não serão muitas as alterações.
Ponto negativo:
Sempre que necessitar atualizar o cliente deverá disponibilizar novo executável do programa atualizador.
Se utilizar procedures, triggers, etc, será necessário algum arquivo com o script com o conteúdo para realizar atualização, pode ser dll ou outro.
Sugestão 2:
Implementar um comparador de base de dados.
O atualizador deverá comparar a base de dados do cliente com uma base original com a estrutura atualizada (sem dados), e executar as alterações necessárias.
Ponto positivo:
Não é necessário enviar executável ao cliente a cada atualização de base de dados.
Não é necessário enviar arquivos auxiliares para procedures, triggers, etc.
Ponto negativo:
Sempre deverá enviar uma base de dados ou script para criar a base com a estrutura atualizada para ser comparada. Dependendo da estrutura da base de dados, a comparação poderá demorar mais que a sugestão 1.
Necessário conhecer muito bem a estrutura das tabelas do sistema do SGBD, se resolver trocar de banco de dados, provavelmente terá um trabalho maior.
Para os dois casos:
Se possível, sempre execute a atualização no servidor, é muito mais rápido.
Não esqueça do backup antes de atualizar.
Espero ter contribuído.
Sim, ajudou sim vou optar pela primeira opção pelo fato que será o processo mais rápido.
Obrigado
Leandroptu
Responder
Gostei + 1
Mais Posts
25/06/2012
Ricardo Rodrigues
Boa tarde Leandro, um exemplo de como eu fiz foi o seguinte, crie um .ini onde guardo a versão do sistema, e uma constante no meu sistema que guarde a versão do .exe. Quando eu executo o projeto o sistema verifica a versão do .ini, exemplo : 1.10, caso a versão do exe seja 2.00 eu execeuto um aplicativo que faz as alterações no banco de dados.
Espero ter ajudado
Att.
Ricardo Rodrigues
Espero ter ajudado
Att.
Ricardo Rodrigues
Responder
Gostei + 0
25/06/2012
Leandroptu
Obrigado por responder, a minha duvida é como que criarei o script no ambiente de desenvolmento e atualizarei somente os novos campos no firebird do cliente (prevalecendo os registros em todas as tabelas), esse procedimento deve funcionar támbem para dominios, triggers e procedures.
Responder
Gostei + 0
25/06/2012
Edinei Colli
Sugestão 1:
Implementar um dicionário de dados com identificação de versão.
Ter um campo na base de dados com a versão do sistema.
Ao rodar o seu atualizador ele irá validar a versão do banco de dados e executar as atualizações necessárias da versão gravada no banco de dados até a versão do seu executável.
Ponto positivo:
O dicionário de dados poderá ser utilizado para outras funcionalidades em todo o sistema.
Se futuramente resolver utilizar outro banco de dados, provavelmente não serão muitas as alterações.
Ponto negativo:
Sempre que necessitar atualizar o cliente deverá disponibilizar novo executável do programa atualizador.
Se utilizar procedures, triggers, etc, será necessário algum arquivo com o script com o conteúdo para realizar atualização, pode ser dll ou outro.
Sugestão 2:
Implementar um comparador de base de dados.
O atualizador deverá comparar a base de dados do cliente com uma base original com a estrutura atualizada (sem dados), e executar as alterações necessárias.
Ponto positivo:
Não é necessário enviar executável ao cliente a cada atualização de base de dados.
Não é necessário enviar arquivos auxiliares para procedures, triggers, etc.
Ponto negativo:
Sempre deverá enviar uma base de dados ou script para criar a base com a estrutura atualizada para ser comparada. Dependendo da estrutura da base de dados, a comparação poderá demorar mais que a sugestão 1.
Necessário conhecer muito bem a estrutura das tabelas do sistema do SGBD, se resolver trocar de banco de dados, provavelmente terá um trabalho maior.
Para os dois casos:
Se possível, sempre execute a atualização no servidor, é muito mais rápido.
Não esqueça do backup antes de atualizar.
Espero ter contribuído.
Implementar um dicionário de dados com identificação de versão.
Ter um campo na base de dados com a versão do sistema.
Ao rodar o seu atualizador ele irá validar a versão do banco de dados e executar as atualizações necessárias da versão gravada no banco de dados até a versão do seu executável.
Ponto positivo:
O dicionário de dados poderá ser utilizado para outras funcionalidades em todo o sistema.
Se futuramente resolver utilizar outro banco de dados, provavelmente não serão muitas as alterações.
Ponto negativo:
Sempre que necessitar atualizar o cliente deverá disponibilizar novo executável do programa atualizador.
Se utilizar procedures, triggers, etc, será necessário algum arquivo com o script com o conteúdo para realizar atualização, pode ser dll ou outro.
Sugestão 2:
Implementar um comparador de base de dados.
O atualizador deverá comparar a base de dados do cliente com uma base original com a estrutura atualizada (sem dados), e executar as alterações necessárias.
Ponto positivo:
Não é necessário enviar executável ao cliente a cada atualização de base de dados.
Não é necessário enviar arquivos auxiliares para procedures, triggers, etc.
Ponto negativo:
Sempre deverá enviar uma base de dados ou script para criar a base com a estrutura atualizada para ser comparada. Dependendo da estrutura da base de dados, a comparação poderá demorar mais que a sugestão 1.
Necessário conhecer muito bem a estrutura das tabelas do sistema do SGBD, se resolver trocar de banco de dados, provavelmente terá um trabalho maior.
Para os dois casos:
Se possível, sempre execute a atualização no servidor, é muito mais rápido.
Não esqueça do backup antes de atualizar.
Espero ter contribuído.
Responder
Gostei + 0
Clique aqui para fazer login e interagir na Comunidade :)