[firebase-br] RES: Backup

[Renato Alexandre]

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
>