[firebase-br] ALTER TABLE CHANNEL_DISPONIBILIDADE DROP CONSTRAINT FK_CHANNEL_DISP_2_TIPOUH

[Julio Sardenberg]

Sim Gladiston. Foi claro sim.

Essa opção já havíamos levado em conta, mas deixamos-a como última
alternativa, pois teremos um grande trabalho para 'desvincula-la' de todo o
restante da base e além disso fica a dúvida de mesmo após tudo isso ser
feito, será que o drop das tabelas funcionará?! Já que haverá ainda a
constraint 'imorrivel' associada a ela.





Em Seg, 16 de abr de 2018 13:21, Gladiston Santana <gladiston em vidy.com.br>
escreveu:

> Deixa eu ser mais claro, apague os dados da tabela-filha, ok, você disse,
> que bom, agora apague os dados da tabela-pai, que ótimo você já fez isso
> também, agora drop a tabela-filha e depois drop a tabela-pai.
> Se não conseguir é porque ainda há IR envolvendo outros tabelas que estão
> ligadas a essas, haver dados é irrelevante, pois a própria ligação IR
> requer que as tabelas-filhos sejam dropadas primeiro até chegar a tabela
> nave-mãe.
>
> espero que tenha sido mais claro.
>
>
> Em 16 de abril de 2018 12:20, Julio Sardenberg <julioc2s em gmail.com>
> escreveu:
>
> > 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
> > ______________________________________________
> > 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
> >
>
>
>
> --
> A Vidy possui um Sistema de Gestão da Qualidade estruturado e com
> Certificação ISO 9001 há mais de 10 anos, mantendo seu foco na Qualidade e
> na Melhoria Continua.
>
> Em março de2018 migramos com sucesso para a nova versão da ISO 9001.
>
> Somos a única Empresa Brasileira de Engenharia de Laboratórios com
> certificação com o Escopo Completo; desde Projetos, Engenharia, Construção,
> Fabricação e Instalação de Laboratórios.
> ______________________________________________
> 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