[firebase-br] RES: Backup

[Claudio Marcio Stocco]

Aconteceu comigo mais de uma vez, mesmo o campo sendo NOT NULL o 
Firebird aceitou ficar nulo. Por isso por isso preferimos deixar de 
criar campos NOT NULL e garantir o preenchimento do campo pela aplicação 
ou via trigger.


Em 20/10/2015 12:36, Renato Alexandre escreveu:
> Se o campo é not null e foi adicionado a tabela o mesmo já deve receber um
> valor inicial ou um valor default.
>
> Em 20 de outubro de 2015 11:28, INFOSOL <contato em infosol.eti.br> escreveu:
>
>>          Carlos, bom dia!!
>>
>>          Já aconteceu isto e não necessariamente seria com tabelas do
>> sistema.
>>          Veja meu caso.
>>          Em uma tabela foi adicionado um campo novo NOT NULL.
>>          Ex: ALTER TABLE XXXXX ADD YYYYYYY char(1) NOT NULL
>>
>>          Se for feito um backup sem atribuir um valor ao campo YYYYYYYY, o
>> backup é realizado, mas quando for ser feito o restore ocorrerá o erro no
>> campo não pode ser NULL, e o restore não será concluído.
>>          Aproveito para perguntar se existe alguma forma de fazer, por
>> exemplo:
>>          1. Apenas extrair o Metadado (isto é possível).
>>          2. Alterar o campo YYYYYYY sem a atribuição do NOT NULL
>>          3. De alguma forma restaurar o backup "pulando" a parte da criação
>> do Metadados e apenas restaurando as tabelas.
>>          Não sei se me compreendeu.
>>
>>          Agradeceria qualquer dica de como poder restaurar um backup que
>> esteja nesta situação de um campo not null.
>>
>>                  Amilcar
>>
>>
>>
>>
>>
>>
>>
>> -----Mensagem original-----
>> De: lista [mailto:lista-bounces em firebase.com.br] Em nome de Carlos H.
>> Cantu
>> Enviada em: terça-feira, 20 de outubro de 2015 09:37
>> Para: FireBase
>> Assunto: Re: [firebase-br] Backup
>>
>> MG> Ao executar um backup pelo GBACK o backup acontece perfeitamente. Porém
>> MG> ao recuperar não recupera. O problema é simples.. é apenas um campo que
>> MG> foi criado e passou a ser obrigatório porém está sem dado algum.
>>
>> Provavelmente porque alguém alterou o campo manipulando diretamente as
>> tabelas de sistema, o que não deveria ser feito.
>>
>> MG> 1) Quando automatizamos o backup queremos que a rotina se torne
>> simples,
>> MG> rápida. Contudo se o backup permite ser feito com esse erro. Somente
>> MG> vamos poder identificá-lo no momento de restaurar, caso aconteça algo
>> MG> com o BD original.
>>
>> Por isso mesmo, toda rotina automatizada de backup deveria testar a
>> restauração também, para ter certeza de que tudo está OK. Utilitários
>> com o DataGuard, fazem isso automaticamente.
>>
>> MG> 2) Existe alguma forma de prepararmos o backup para que finalize com
>> MG> erro caso encontre problemas de integridade de dados? (no momento de
>> MG> fazer o backup e não no momento de restaurá-lo).
>>
>> O erro em questão é um erro lógico, e não "físico", portanto, não há
>> como você saber da existência dele durante o backup... apenas no
>> restore.
>>
>> []s
>> Carlos H. Cantu
>> www.FireBase.com.br - www.firebirdnews.org
>> www.warmboot.com.br - blog.firebase.com.br
>>
>>
>> ______________________________________________
>> 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://www.firebase.com.br/pesquisa_lista.html
>>
>>
>> ______________________________________________
>> 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://www.firebase.com.br/pesquisa_lista.html
>>
> ______________________________________________
> 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://www.firebase.com.br/pesquisa_lista.html