[firebase-br] RES: Backup

[Rafael - FAV Ferro e Aço]

Amigos, na minha opinião, temos aqui uma diferença de abordagens.
Ao permitir criar um campo NOT NULL novo em tabelas já populadas, o
Firebird delega a responsabilidade de manter a integridade dos dados para o
mantenedor da base, mas infelizmente sabemos que nem toda instituição tem
gente capacitada para isso, logo essas situações são até comuns.
Além do Firebird só tenho experiência com o Oracle e nele, nesse cenário,
só é possível criar o campo novo NOT NULL caso haja um favor DEFAULT, pois
assim o banco já popula os registros antigos com esse valor. Depois que
todos os registros ficam "arrumados" é possível excluir a cláusula DEFAULT.
Não estou dizendo que uma base seja melhor que outra nem nada disso, como
eu disse, são abordagens diferentes.
Cantu, haveria algum estudo de se implementar esse tipo de controle em
versões futuras do FB?



--
Rafael Cardoso Stella
Gerente Financeiro
FAV Comércio de Ferro e Aço LTDA
Fone: (15) 3229-5050 - (11) 4523-5833 - FAX: (15) 3229-5055
rafael.sorocaba em favcomercial.com.br
http://www.favcomercial.com.br

Em 20 de outubro de 2015 17:05, Carlos H. Cantu <listas em warmboot.com.br>
escreveu:

> Nunca o Firebird deixará que você insira registros com campos not null
> nulos.
>
> []s
> Carlos H. Cantu
> www.FireBase.com.br - www.firebirdnews.org
> www.warmboot.com.br - blog.firebase.com.br
>
> CMS> Aconteceu comigo mais de uma vez, mesmo o campo sendo NOT NULL o
> CMS> Firebird aceitou ficar nulo. Por isso por isso preferimos deixar de
> CMS> criar campos NOT NULL e garantir o preenchimento do campo pela
> aplicação
> CMS> ou via trigger.
>
>
> CMS> 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
>
>
> ______________________________________________
> 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
>