[firebase-br] ALTER TABLE CHANNEL_DISPONIBILIDADE DROP CONSTRAINT FK_CHANNEL_DISP_2_TIPOUH

[Gladiston Santana]

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
>
>