[OT] Discussão sobre atualização de base de dados
Pessoal,
Posso abrir uma discussão?
Como vocês fazem atualização da base de dados quando há inclusão de novas tabelas, campos, triggers e etc?
[list:4b845ee1d9]
[*:4b845ee1d9] Via script SQL?
[*:4b845ee1d9] Software + Script?
[*:4b845ee1d9] Outros métodos.
[/list:u:4b845ee1d9]
Não quero abrir uma enquete. Aqui na empresa não temos isso, gostaria de criar uma rotina automática, mas o problema maior é: E se existirem usuários conectados a base??? E outros fatores que podem contribuir para ocasionarem erros na atualização de base.
Valeu
Obs. A base que usamos é Firebird, mas poderíamos usar isso para outras bases também.
Posso abrir uma discussão?
Como vocês fazem atualização da base de dados quando há inclusão de novas tabelas, campos, triggers e etc?
[list:4b845ee1d9]
[*:4b845ee1d9] Via script SQL?
[*:4b845ee1d9] Software + Script?
[*:4b845ee1d9] Outros métodos.
[/list:u:4b845ee1d9]
Não quero abrir uma enquete. Aqui na empresa não temos isso, gostaria de criar uma rotina automática, mas o problema maior é: E se existirem usuários conectados a base??? E outros fatores que podem contribuir para ocasionarem erros na atualização de base.
Valeu
Obs. A base que usamos é Firebird, mas poderíamos usar isso para outras bases também.
Adriano Santos
Curtidas 0
Respostas
Luciano.sul
29/03/2006
Adriano Santos, eu faço assim. Eu uso o ibexpert e toda a alteracao que eu faco no banco o ibexpert gera o codigo da mundaca. este codigo eu gravo em uma arquivo texto, dai eu fiz um programa a parte do meu que o usuario quando instala o meu sistema ele tambem leva este programa. e toda a vez que sai uma versao nova do meu sistema junto com o executavel o cliente leva um arquivo texto. dai ele antes de atualizar o executavel ele abre este arquivo texto neste programa que eu te falei e gera o script. A minha ideia mais tarde vai ser o seguinte no meu banco vai ter uma campo em uma determinada tabela que ira dizer a versao do banco e se a versao do banco for diferente do executavel este executavel gera altomaticamente o script....
Espero ter ficado claro...
Até mais
Luciano Ramos
Espero ter ficado claro...
Até mais
Luciano Ramos
GOSTEI 0
Adriano Santos
29/03/2006
[b:3b26aca962]luciano.sul[/b:3b26aca962] entendi.
Em outra empresa que trabalhei havia uma unit que fazia a atualização automática. Eram uma série de procedures referentes a cada atualização do sistema por exemplo:
Depois em uma outra procedure faziamos a verificação da versão do banco:
Daí no onShow desta Unit disparávamos a procudure:
[b:3b26aca962]VersaoSoftware[/b:3b26aca962] era uma variável global no código fonte e que mudávamos cada vez que saia uma nova versão.
Bem, isso é bem feio, eu acho, quando entrei na empresa já era assim. Mesmo sendo feio funionava, mas se houvesse alguém conectado na base dava erro ou a tabela em questão não era atualizada, mas não mostrava o erro porque o except estava sempre vazio:
Bom, vamos fazer umas mudanças no software que estou trabalhando nesta nova empresa, então não quero ter que fazer um algoritimo como o de cima.
Vlw...ufa, tô sendo detalhista né?
Em outra empresa que trabalhei havia uma unit que fazia a atualização automática. Eram uma série de procedures referentes a cada atualização do sistema por exemplo:
procedure AtualizaVersao_1001; begin with MeuCompQuery do begin Close; UnPrepare; Sql.Clear; Sql.Add(´ALTER TABLE MINHA_TABELA ADD COLUMN NOVO_CAMPO VARCHAR(100) NOT NULL´); Try ExecSql; Except end; end; end; procedure AtualizaVersao_1002; begin with MeuCompQuery do begin Close; UnPrepare; Sql.Clear; Sql.Add(´ALTER TABLE MINHA_TABELA ADD COLUMN NOVO_CAMPO VARCHAR(50) NOT NULL´); Try ExecSql; Except end; end; end; procedure AtualizaVersao_1003; begin with MeuCompQuery do begin Close; UnPrepare; Sql.Clear; Sql.Add(´ALTER TABLE MINHA_TABELA ADD COLUMN NOVO_CAMPO VARCHAR(100) NOT NULL´); Try ExecSql; Except end; end; end;
Depois em uma outra procedure faziamos a verificação da versão do banco:
procedure DisparaAtualizacoes; var Versao: String; begin with MinhaQuery do begin Close; UnPrepare; Sql.Clear; Sql.Add(´SELECT VERSAO FROM TABELA_CONFIG WHERE PARAMETRO=:PARAMETRO´); ParamByName(´PARAMETRO´).AsString := ´VERSAO´; Versao := FieldByName(´VERSAO´).AsString; Close; end; if VersaoSoftware = Versao then for I := 0 to 2 do begin case I of 0: AtualizaVersao_1001; 1: AtualizaVersao_1002; 2: AtualizaVersao_1003; end; end; end;
Daí no onShow desta Unit disparávamos a procudure:
procedure TAtualizaBancoShow()........ begin DisparaAtualizacoes; end;
[b:3b26aca962]VersaoSoftware[/b:3b26aca962] era uma variável global no código fonte e que mudávamos cada vez que saia uma nova versão.
Bem, isso é bem feio, eu acho, quando entrei na empresa já era assim. Mesmo sendo feio funionava, mas se houvesse alguém conectado na base dava erro ou a tabela em questão não era atualizada, mas não mostrava o erro porque o except estava sempre vazio:
Try ExecSql; Except end;
Bom, vamos fazer umas mudanças no software que estou trabalhando nesta nova empresa, então não quero ter que fazer um algoritimo como o de cima.
Vlw...ufa, tô sendo detalhista né?
GOSTEI 0
Luciano.sul
29/03/2006
Sabes eu não achei uma ma ideia(procedures). :D Vou dar uma estuda melhor neste assunto... Hoje o que eu faço eu nunca encontrei problemas, mas quanto menas operação o cliente tiver que fazer para atualizar o sistema é melhor.
No meu caso o cliente sai do sistema para atualizar a base..., acho que disto eu nao vou conseguir fugir...
Até mais.
Luciano Ramos
No meu caso o cliente sai do sistema para atualizar a base..., acho que disto eu nao vou conseguir fugir...
Até mais.
Luciano Ramos
GOSTEI 0
Adriano Santos
29/03/2006
Sabes eu não achei uma ma ideia(procedures). :D
Como eu falei, funciona, porém acho uma idéia chucra. Eu tentaria ao máximo reduzir o algoritimo pra ficar mais simples.
No meu caso o cliente sai do sistema para atualizar a base..., acho que disto eu nao vou conseguir fugir...
Dá pra fugir sim [b:56dd42bde3]Luciano[/b:56dd42bde3], como disse, o sistema compara a versão (presente no código fonte) com a versão que está no banco e então dispara as atualizações. Funciona que é uma beleza, mas tem o fato que mencionei.
Imagina vc incluir um novo campo na tabela Clientes, entretanto uma porrada de gente tah conectado na tabela. Não funciona. Ai vc tem que mandar todo mundo sair do sistema.
Tô pesquisando no fórum Interbase/Firebird pra ver se acho alguma discussão a respeito. O que estou pensando em fazer é algo mais complexo.
[list:56dd42bde3]
[*:56dd42bde3] Compara versões.
[*:56dd42bde3] Verfica se existem ususários conectados ao banco.
[*:56dd42bde3] Se existirem, mostra uma tela com os caras e com opção para enviar mensagem a todos os usuários avisando que o sistema será atualizado e portanto os mesmo serão desconctados.
[*:56dd42bde3] Desconecta todo mundo.
[*:56dd42bde3] Dispara atualizações.
[*:56dd42bde3] Avisa todo mundo pra voltar a usar o sistema.
[/list:u:56dd42bde3]
Sonho né? Mas se bem projetado, fica legal.
Tah certo que se migrarmos mesmo para DBExpress aqui, não teremos este problema de ´nego´ conectado no banco, pois mudaremos a engenharia do sistema.
É isso, agradeceria se outros colegas postassem suas opniões.
Vlw
GOSTEI 0
Michael
29/03/2006
Aqui usamos um sistema de [b:f5aa181831]patches[/b:f5aa181831]. Temos um script SQL para a criação do banco, e depois para cada atualização criamos um com as alterações necessários. Depois usamos um programa que criamos para executar os scripts e atualizar o banco de dados.
O programa verifica se a versão do banco é a esperada para a atualização, e a aplicação principal só roda se o banco estiver na versão correta.
Quanto aos usuários conectados, o processo é realizado geralmente em um horário de pouca utilização, o que não compromete a tarefa. E se for necessário algo rápido, então todos desconectam manualmente. Não acho legal fechar o programa automaticamente pois algum usuário pode estar fazendo algo importante e ele teria seu trabalho perdido.
É simples e funciona até hoje. ;-)
[]´s
O programa verifica se a versão do banco é a esperada para a atualização, e a aplicação principal só roda se o banco estiver na versão correta.
Quanto aos usuários conectados, o processo é realizado geralmente em um horário de pouca utilização, o que não compromete a tarefa. E se for necessário algo rápido, então todos desconectam manualmente. Não acho legal fechar o programa automaticamente pois algum usuário pode estar fazendo algo importante e ele teria seu trabalho perdido.
É simples e funciona até hoje. ;-)
[]´s
GOSTEI 0
Adriano Santos
29/03/2006
...Não acho legal fechar o programa automaticamente pois algum usuário pode estar fazendo algo importante e ele teria seu trabalho perdido.
Então, neste caso eu daria um tempo pra ele fechar. Tipo, após o recebimento da mensagem o programa ainda iria esperar um tempo. Mas sei lá, coisas automáticas demais acabam resultando em problemas. Concordo contigo.
Vlw
GOSTEI 0
Weber
29/03/2006
Eu trabalho com sistema de Script´s, mas desenvolvi uma vez para um cliente uma rotina que funciona mais ou menos assim:
Banco FireBird
Pego um banco de dados 100¬ atualizado, o que eu chamo de Default, carrego tabela por tabela, campo por campo, trigger por trigger do banco Default e comparo com o banco a ser atualizado, quando há diferenças a rotina faz a atualização.
Deu o maior trabalhão pra montar e a rotina ficou super lenta, mas como o cliente estava pagando :lol:
Tive que fazer diversas verificações:
- Campo não existe: Criar o Campo
- Campo existe mas não é chave: Transformar em chave, mas antes ver se não há informações que possam corromper o banco.
- Campo existe mas é de tipo diferente: Verificar possibilidade de migrar as informações
- Além de mais umas dezenas de verificações.
Com as triggers, views, excepts moleza, sempre mato tudo depois crio de novo.
Infelizmente não posso divulgar o código fonte, seria antiético
Banco FireBird
Pego um banco de dados 100¬ atualizado, o que eu chamo de Default, carrego tabela por tabela, campo por campo, trigger por trigger do banco Default e comparo com o banco a ser atualizado, quando há diferenças a rotina faz a atualização.
Deu o maior trabalhão pra montar e a rotina ficou super lenta, mas como o cliente estava pagando :lol:
Tive que fazer diversas verificações:
- Campo não existe: Criar o Campo
- Campo existe mas não é chave: Transformar em chave, mas antes ver se não há informações que possam corromper o banco.
- Campo existe mas é de tipo diferente: Verificar possibilidade de migrar as informações
- Além de mais umas dezenas de verificações.
Com as triggers, views, excepts moleza, sempre mato tudo depois crio de novo.
Infelizmente não posso divulgar o código fonte, seria antiético
GOSTEI 0
Adriano Santos
29/03/2006
Infelizmente não posso divulgar o código fonte, seria antiético
Tranquilo [b:5570f77e9c]weber[/b:5570f77e9c] essa não é a idéia, o que quero realmente é apenas discutir a respeito pra buscar um parâmetro, assim eu consigo pensar na melhor ou mais rápida forma de fazê-lo.
Vlw
GOSTEI 0
Luciano.sul
29/03/2006
Michael o meu procedimento é igual ao seu sem a parte de [ O programa verifica se a versão do banco é a esperada para a atualização, e a aplicação principal só roda se o banco estiver na versão correta. ]
Mas mesmo fazendo assim eu achei bem legal o modo de procedures, pois ai eu tiro o trabalho do cliente em abrir um outro programa para atualizar o banco. Simplemente o cliente só tera o trabalho de mudar o executavel.
É isso ai..., é muito bom trocar ideias.
Luciano Ramos
Mas mesmo fazendo assim eu achei bem legal o modo de procedures, pois ai eu tiro o trabalho do cliente em abrir um outro programa para atualizar o banco. Simplemente o cliente só tera o trabalho de mudar o executavel.
É isso ai..., é muito bom trocar ideias.
Luciano Ramos
GOSTEI 0
Adriano Santos
29/03/2006
Mas mesmo fazendo assim eu achei bem legal o modo de procedures, pois ai eu tiro o trabalho do cliente em abrir um outro programa para atualizar o banco. Simplemente o cliente só tera o trabalho de mudar o executavel.
[b:4959d19405]Luciano[/b:4959d19405], a única coisa que achei ruim na realidade, embora funcione, é que tem que ficar bem atento quanto mexer na unit de atualização, ou seja:
[list:4959d19405]
[*:4959d19405] Criar uma nova procedure para incluir o script de atualização.
[*:4959d19405] Alterar o ´index´ do FOR de [b:4959d19405][color=blue:4959d19405]for I := 0 to 2 do...[/color:4959d19405][/b:4959d19405] para [b:4959d19405][color=red:4959d19405]for I := 0 to 9 do...[/color:4959d19405][/b:4959d19405] por exemplo.
[*:4959d19405] Incluir a chamada para a nova procedure.
[/list:u:4959d19405]
Até ai beleza, mas conforme as versões vão sendo lançadas o nosso For vai aumentando. Depois de um tempo, acho que fica ruim para dar manutenção em equipe, entende?
if VersaoSoftware = Versao then for I := 0 to 9 do begin case I of 00: AtualizaVersao_1001; 01: AtualizaVersao_1002; 02: AtualizaVersao_1003; 04: AtualizaVersao_1004; 05: AtualizaVersao_1005; 06: AtualizaVersao_1006; 07: AtualizaVersao_1007; 08: AtualizaVersao_1007; 09: AtualizaVersao_1008; 10: AtualizaVersao_1010; end; end;
10 versões diferentes já ficariam assim, imaginem 2, 3 anos de vida do software? Por isso abri a discussão, pra ter uma idéia de como o mercado costuma fazer.
GOSTEI 0
Michael
29/03/2006
Michael o meu procedimento é igual ao seu sem a parte de [ O programa verifica se a versão do banco é a esperada para a atualização, e a aplicação principal só roda se o banco estiver na versão correta. ]
Acho isso importante pois se a aplicação usar a tabela A, e ela não existir no banco de dados, um erro pode ocorrer durante sua execução.
Mas mesmo fazendo assim eu achei bem legal o modo de procedures, pois ai eu tiro o trabalho do cliente em abrir um outro programa para atualizar o banco. Simplemente o cliente só tera o trabalho de mudar o executavel.
Quem atualiza o banco de dados e os demais arquivos aqui na empresa é a equipe de infra-estrutura, e não o cliente. E, mesmo que fosse, o nosso programa de atualização é extremamente fácil de se usar. Basta abrí-lo e pronto. ;-)
té ai beleza, mas conforme as versões vão sendo lançadas o nosso For vai aumentando. Depois de um tempo, acho que fica ruim para dar manutenção em equipe, entende?
[b:3eef350abb]Adriano[/b:3eef350abb], esse é outra vantagem de se usar patches: podem haver centenas deles, por exemplo. Cada arquivo funciona independente do outro. Basta criá-lo e configurar o programa de atualização.
[]´s
GOSTEI 0
Massuda
29/03/2006
...outra vantagem de se usar patches: podem haver centenas deles, por exemplo. Cada arquivo funciona independente do outro. Basta criá-lo e configurar o programa de atualização.
Não conheço o seu sistema de geração de patches, mas geralmente existe uma ordem de aplicação do patch (por exemplo, o patch da versão 1->2 precisa ser aplicado antes do patch da versão 2->3); algumas pessoas costumam gerar patch de uma versão muito utilizada (mas não necessariamente ´penultima´ versão) para a última versão (a mais recente) para poupar trabalho na hora de aplicar os patches.GOSTEI 0
Adriano Santos
29/03/2006
[b:b3c787a6cc]Adriano[/b:b3c787a6cc], esse é outra vantagem de se usar patches: podem haver centenas deles, por exemplo. Cada arquivo funciona independente do outro. Basta criá-lo e configurar o programa de atualização.
Eu entendi [b:b3c787a6cc]Michael[/b:b3c787a6cc], é que, infelizmente, a empresa que trabalho atualmente é pequena e não temos uma equipe de infra-estrutura e o suporte é feito por um cara somente e nem sempre ele está na empresa, pois visita clientes o tempo todo também.
Nosso sistema é voltado ao mercado de transportes, ou seja, atende transportadoras de todo porte. A grande maioria de usuários que utilizam o sistema são pessoas com nível de conhecimento bem baixo, e as vezes o simples abrir o site, baixar o programa, encontrar o arquivo no hd e abrir, vixi tem vezes que se torna inviável. Temos que mandar o suporte ir ao local, manja?
Por isso quero criar algo o mais simples possível. Não estou dizendo que a sua idéia não me convenceu, muito pelo contrário, apenas estou averiguando o que eu posso fazer de mais tranquilo possível para o usuário final.
Vlw véio.
GOSTEI 0
Titanius
29/03/2006
[quote:1081aaa213=´Michael´]...outra vantagem de se usar patches: podem haver centenas deles, por exemplo. Cada arquivo funciona independente do outro. Basta criá-lo e configurar o programa de atualização.
Não conheço o seu sistema de geração de patches, mas geralmente existe uma ordem de aplicação do patch (por exemplo, o patch da versão 1->2 precisa ser aplicado antes do patch da versão 2->3); algumas pessoas costumam gerar patch de uma versão muito utilizada (mas não necessariamente ´penultima´ versão) para a última versão (a mais recente) para poupar trabalho na hora de aplicar os patches.[/quote:1081aaa213]Entrando no assunto,
Hoje faço a mesma coisa que foi dito anteriormente por um amigo, eu pego os scripts pelo IBExpert, e executo no cliente, mas como disse o amigo, isso se torna inviavel a grande prazo, eu por exemplo já tenho mais 200 scripts... é complicado... agora esse sistema de patch é interessante... qnt à criar, poderia ser criado um patch pra cada atualizacao ou um ´super-patch´ com todos os patch, entendeu?
Mas como eh feito isso? existe algum software para isso, ou tenho que desenvolver tambem ese sistema?
[]s
GOSTEI 0
Adriano Santos
29/03/2006
Entrando no assunto,
Hoje faço a mesma coisa que foi dito anteriormente por um amigo, eu pego os scripts pelo IBExpert, e executo no cliente, mas como disse o amigo, isso se torna inviavel a grande prazo, eu por exemplo já tenho mais 200 scripts... é complicado... agora esse sistema de patch é interessante... qnt à criar, poderia ser criado um patch pra cada atualizacao ou um ´super-patch´ com todos os patch, entendeu?
Mas como eh feito isso? existe algum software para isso, ou tenho que desenvolver tambem ese sistema?
[]s
Pode crer [b:49a97253b2]titanius[/b:49a97253b2], eu entendi a idéia do [b:49a97253b2]Michael[/b:49a97253b2] só não consegui associar isso visualmente a minha aplicação. Pode detalhar um pouco mais o esquema [b:49a97253b2]Michael[/b:49a97253b2] pra gente?
Obs. Hoje na empresa nós temos os scripts para atualização da base de dados, porém nós enviamos ao usuário o arquivo .SQL ele executa o mesmo no IBOConsole, o que acho complexo demais para o tipo de usuário que temos, como falei anteriormente. Quando o usuário é muito ruim de informática a gente manda o rapaz do suporte técnico para realizar a atualização da base.
Vlw
GOSTEI 0
Massuda
29/03/2006
Acho que você poderia incluir nos scripts SQL (talvez manualmente) informações sobre versão (ou algo que permita identificar que o script atualiza de tal versão para tal versão, por exemplo, nome do script) e incluir no seu programa um procedure de inicialização de checasse os scripts existentes na máquina e aplicasse aqueles que fossem necessários. Isso seria um misto do que foi dito até agora.
GOSTEI 0
Gilberto Fernandes
29/03/2006
interessante essa discussão, no meu sistema a gente criou uma tela dentro do sistema, uma espécie de editor onde colocamos o script q será executado como no ibconsole, o meu problema é qdo o script tem comandos de chave estrangeira, chave primária, as vezes não da msg de erro nenhuma mas as chaves não são criadas, depois descobrir isso no cliente é foda...
GOSTEI 0
Michael
29/03/2006
Não conheço o seu sistema de geração de patches, mas geralmente existe uma ordem de aplicação do patch (por exemplo, o patch da versão 1->2 precisa ser aplicado antes do patch da versão 2->3); algumas pessoas costumam gerar patch de uma versão muito utilizada (mas não necessariamente ´penultima´ versão) para a última versão (a mais recente) para poupar trabalho na hora de aplicar os patches.
Correto [b:6d5659a8c0]Massuda[/b:6d5659a8c0], a ordem de execução deve ser respeitada rigorasamente para não ocorrem erros.
Até pouco tempo nós mantínhamos duas versões de scripts: uma total, que mesclava todos os patches, e eles propriamente ditos. O problema desta abordagem é que manter dois arquivos parecidos é difícil, e muito propenso a erros. Por isso hoje só usamos criamos patches. Como temos um software para aplicá-los, o trabalho é quase nenhum entre usar um só arquivo ou vários.
qnt à criar, poderia ser criado um patch pra cada atualizacao ou um ´super-patch´ com todos os patch, entendeu?
Foi o que eu disse acima. Quando uma release da aplicação é fechado, um arquivo com todos os patches até o momento é criado. Este seria o ´super-patche´ que vc mencionou.
Acho que você poderia incluir nos scripts SQL (talvez manualmente) informações sobre versão (ou algo que permita identificar que o script atualiza de tal versão para tal versão, por exemplo, nome do script) e incluir no seu programa um procedure de inicialização de checasse os scripts existentes na máquina e aplicasse aqueles que fossem necessários. Isso seria um misto do que foi dito até agora.
Na mosca de novo [b:6d5659a8c0]Massuda[/b:6d5659a8c0]. Cada patch verifica e atualiza a versão do banco de dados, em uma tabela de configuração. Desta forma o script da versão 3.4, por exemplo, só vai rodar se a versão atual do banco for a 3.3. O detalhe é que tudo isso é feito via SQL apenas, sem nenhuma programação externa. Nós só utilizamos um aplicativo à parte pq ele separa todos os batches do patch (engraçado...) e os executa individualmente dentro de uma transação. Se algum erro ocorrer, então um rollback é chamado e o processo é interrompido. Isso foi necessário pq se o script fosse executado, por exemplo, no SQL Server, e algum problema acontecesse, mesmo que uma exceção fosse levantada o restante do arquivo ainda seria compilado, e o banco ficaria corrompido.
Por último se a aplicação for dependente de algum patch, então ela verifica a versão do banco antes de carregar e exibe uma exceção para o usuário no caso da versão ser incompatível com as funcionalidades do programa.
[]´s
GOSTEI 0
Martins
29/03/2006
[quote:69fa6d1746=´Adriano Santos´]
Pode crer [b:69fa6d1746]titanius[/b:69fa6d1746], eu entendi a idéia do [b:69fa6d1746]Michael[/b:69fa6d1746] só não consegui associar isso visualmente a minha aplicação. Pode detalhar um pouco mais o esquema [b:69fa6d1746]Michael[/b:69fa6d1746] pra gente?
Obs. Hoje na empresa nós temos os scripts para atualização da base de dados, porém nós enviamos ao usuário o arquivo .SQL ele executa o mesmo no IBOConsole, o que acho complexo demais para o tipo de usuário que temos, como falei anteriormente. Quando o usuário é muito ruim de informática a gente manda o rapaz do suporte técnico para realizar a atualização da base.
Vlw[/quote:69fa6d1746]
Pelo visto, nesse tópico as idéais vão rolar a vontade, quanto a essa questão de Patchs é interessante, só q eu não sei como se faz isso, nunca fiz :cry:, se alguém puder dar uma dica :lol:, acho interessante alguns sistemas q rodam por aqui como o CNS(Conectividade Social) ao abrirmos ele, o mesmo deve verificar em um servidor se há uma verão mais recente e atualiza-se automaticamente, recurso interessante para quem dispõe de um servidor, mas para quem tem q enviar os arquivos para o cliente e pelo q li até agora os patchs são o melhor caminho, tem sistema q uma vez atualizado, se vc por engano tentar executar um patch dele e esse for de uma versão menor, vc é informado e o patch é abortado.
Vamos esperar por mais idéias.
:wink:
Entrando no assunto,
Hoje faço a mesma coisa que foi dito anteriormente por um amigo, eu pego os scripts pelo IBExpert, e executo no cliente, mas como disse o amigo, isso se torna inviavel a grande prazo, eu por exemplo já tenho mais 200 scripts... é complicado... agora esse sistema de patch é interessante... qnt à criar, poderia ser criado um patch pra cada atualizacao ou um ´super-patch´ com todos os patch, entendeu?
Mas como eh feito isso? existe algum software para isso, ou tenho que desenvolver tambem ese sistema?
[]s
Pode crer [b:69fa6d1746]titanius[/b:69fa6d1746], eu entendi a idéia do [b:69fa6d1746]Michael[/b:69fa6d1746] só não consegui associar isso visualmente a minha aplicação. Pode detalhar um pouco mais o esquema [b:69fa6d1746]Michael[/b:69fa6d1746] pra gente?
Obs. Hoje na empresa nós temos os scripts para atualização da base de dados, porém nós enviamos ao usuário o arquivo .SQL ele executa o mesmo no IBOConsole, o que acho complexo demais para o tipo de usuário que temos, como falei anteriormente. Quando o usuário é muito ruim de informática a gente manda o rapaz do suporte técnico para realizar a atualização da base.
Vlw[/quote:69fa6d1746]
Pelo visto, nesse tópico as idéais vão rolar a vontade, quanto a essa questão de Patchs é interessante, só q eu não sei como se faz isso, nunca fiz :cry:, se alguém puder dar uma dica :lol:, acho interessante alguns sistemas q rodam por aqui como o CNS(Conectividade Social) ao abrirmos ele, o mesmo deve verificar em um servidor se há uma verão mais recente e atualiza-se automaticamente, recurso interessante para quem dispõe de um servidor, mas para quem tem q enviar os arquivos para o cliente e pelo q li até agora os patchs são o melhor caminho, tem sistema q uma vez atualizado, se vc por engano tentar executar um patch dele e esse for de uma versão menor, vc é informado e o patch é abortado.
Vamos esperar por mais idéias.
:wink:
GOSTEI 0
Helio Nascimento
29/03/2006
Caro amigo Michael
Voce como colunista da Revista Clube Delphi poderia lançar um artigo deste de como desenvolver estes sistemas de atualização para quem não sabe fazer o passo a passo. Acho uma ideia boa e teria bastante aceitação na vendagem o que vc acha?
Sds/Hélio
Voce como colunista da Revista Clube Delphi poderia lançar um artigo deste de como desenvolver estes sistemas de atualização para quem não sabe fazer o passo a passo. Acho uma ideia boa e teria bastante aceitação na vendagem o que vc acha?
Sds/Hélio
GOSTEI 0
Adriano Santos
29/03/2006
[quote:0a9a88be0b=´Helio Nascimento´]Caro amigo Michael
Voce como colunista da Revista Clube Delphi poderia lançar um artigo deste de como desenvolver estes sistemas de atualização para quem não sabe fazer o passo a passo. Acho uma ideia boa e teria bastante aceitação na vendagem o que vc acha?
Sds/Hélio[/quote:0a9a88be0b]
Oi Hélio, é um bom assunto acho que podemos dar sugestões na próxima reunião certo Michael ?
Voce como colunista da Revista Clube Delphi poderia lançar um artigo deste de como desenvolver estes sistemas de atualização para quem não sabe fazer o passo a passo. Acho uma ideia boa e teria bastante aceitação na vendagem o que vc acha?
Sds/Hélio[/quote:0a9a88be0b]
Oi Hélio, é um bom assunto acho que podemos dar sugestões na próxima reunião certo Michael ?
GOSTEI 0
Michael
29/03/2006
Boa idéia! ;-)
Vamos colocar na pauta para as próximas edições. ;-)
[]´s
Vamos colocar na pauta para as próximas edições. ;-)
[]´s
GOSTEI 0
Adriano Santos
29/03/2006
Boa idéia! ;-)
Vamos colocar na pauta para as próximas edições. ;-)
[]´s
Michael, dei um toque par ao Bruno Lichot via msn e ele também concordou em verificar isso. Se for o caso ele pode montar o artigo também.
Helio, vamos colocar na pauta da nossa próxima reunião ok?
GOSTEI 0
Helio Nascimento
29/03/2006
Adriano Santos/Michael
Muito bom, estarei aguardando o lançamento. Obrigado pela atençao.
Saudações/Hélio
Muito bom, estarei aguardando o lançamento. Obrigado pela atençao.
Saudações/Hélio
GOSTEI 0