[firebase-br] ALTER TABLE CHANNEL_DISPONIBILIDADE DROP CONSTRAINT FK_CHANNEL_DISP_2_TIPOUH

[Julio Sardenberg]

Olá  Gladiston, MUITO obrigado pelo feedback.

O problema amigo, como disse no texto original, eu já apaguei TODOS os
registros da tabela em questão! Mesmo assim a constraint reclama!!!

Eu não entendi isso, pois teoricamente DELETAR uma Constraint não deveria
verificar se a integridade nos dados está OK, mas a situação é ainda mais
bisonha, pois a tabela está VAZIA!


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%





Julio Sardenberg

+55 21 97371 5247

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

Em 16 de abril de 2018 12:13, Gladiston Santana <gladiston em vidy.com.br>
escreveu:

> O programador anterior tava de parabens, fez a integridade referencial
> usando cascade.
> Programas automatizados sem uma IA adequada tem dificuldades em agir em
> tabelas que possuem integridade referencial (IR).
> Mas a idéia é essa mesma, impedir traquinagens que possam fazer perder
> dados que mais tarde serão sentidos, especialmente deixando registros
> orfãos.
> Para intervir, você terá de sujar as mãos excluindo manualmente os dados da
> tabela filha(ou colocando null na posição), se a tabela filha tiver tambem
> IR então fazer essa primeiro antes da anterior e assim sucessivamente.
> Entende porque alguns não gostam de IR?
> Se você conseguir mudar o alter table para um 'cascade delete', voce
> mata-um e morre todos os filhos, eu tomo muito cuidado com IR assim, pois
> numa equipe com muitos desenvolvedores multi-disciplnares alguém resolve
> apagar uma empresa do banco de dados e some até o zézimo pedido.
> No FB3 tem uma opção do restore que pode ignorar uma tabela, eu li isso no
> lançamento, vale a pena conferir e ver se voce consegue restaurar o banco
> sem as tabelas indesejadas.
>
> []´s e boa sorte.
>
> Em 13 de abril de 2018 17:06, Julio Sardenberg <julioc2s em gmail.com>
> escreveu:
>
> > Boa tarde de sexta feira 13!  🙂
> >
> > Galera, estou com um probleminha aqui.  😊 Vou tentar ser sucinto:
> >
> > Tenho um banco num cliente que possui uma tabela com dois campos
> > (FKCODHOTEL e FKCODTIPOUH) que não existem mais no nosso banco de
> > homologação. Então quando fazemos o 'compare' (pelo IB) o script de
> > resultado tenta apagar uma contraint que usa esses dois campos fechando
> com
> > outra tabela. Quando esse 'ALTER TABLE DROP CONSTAINT ' é executado
> > recebemos :
> > ************
> > SQL> ALTER TABLE CHANNEL_DISPONIBILIDADE DROP CONSTRAINT
> > FK_CHANNEL_DISP_2_TIPOUH;
> > Statement failed, SQLSTATE = 42000
> > unsuccessful metadata update
> > -ERASE RDB$RELATION_CONSTRAINTS failed
> > -action cancelled by trigger (1) to preserve data integrity
> > -Cannot delete trigger used by a CHECK Constraint
> > -At trigger 'RDB$TRIGGER_34'
> > ************
> >
> > Imaginando que pudesse ser algum registro que não estivesse 'fechando'
> > relacionamento entre as tabelas (mesmo achando que não justificaria
> impedir
> > um drop) apaguei os dados das duas tabelas. Mesmo assim ocorre o problema
> > acima!
> >
> > Tem alguma idéia? Já fiz até backup / restore e nada!
> >
> >
> > Julio Sardenberg
> >
> >
> ______________________________________________
> 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