Ciclo infinito de triggers?

[DCD 1]

Estou com um problema teorico com triggers e não estou a encontrar solução, pode ser que alguém me consiga ajudar aqui.

 

Suponhamos as seguintes tabelas:

 

Tabela_A

Campo1

Campo2

Campo3

 

Tabela_B

Campo4

Campo5

Campo6

 

Tabela_C

Campo7

Campo8

Campo9

 

Suponhamos que tenho um trigger (1) na Tabela_A que após upgrade faz um upgrade na Tabela_B. A Tablela_B tem um trigger (2) que após upgrade da Tabela_B faz um upgrade da Tabela_C e um upgrade da Tabela_A. A questão é esta: Depois de executar o trigger da Tabela_B o SQL não repete o trigger da Tabela_A? É que se é assim vou entrar num ciclo infinito e o SQL não tem como sair, certo? Se assim não for, ao efetuar o trigger da Tabela_A o trigger da tabela_B não é executado e a Tabela_C não é actualizada pelo trigger da Tabela_B. Certo?

[samirbh 0]

Ola DCD,

 

pra melhor entendimento você tem que ter em mente que triggers tralham em cima de eventos (mais preciso DML) como insert, delete e update.

 

Como tudo comeca na tabela A é uma boa ideia tudo acabar na mesma com um if

 

por exemplo

 

tabela B recebe um trigger de insert por exemplo sendo assim a mesma vai fazer um delete na tabela c

porque nao tratar a saida da trigger da tabela c conforme que quando ir para a tabela A a trigger pega um resultado e da um break tipo:

 

if(exists(select 1 from tebelaA where condicao))

break

else

continue a va para a tabela B e depois para a C e depois cai no if da tabelaA e assim por diante

 

espero ter ajudado

qualquer coisa...

[DCD 1]

Antes de mais obrigado pela sua resposta Samirbh. Foi útil, ajudou a arrumar ideias.

 

No entanto o problema mantém-se. Estou a trabalhar num ambiente gráfico para o MySQL com especial enfoque na documentação comercial e contabilística. O objectivo é fornecer software de gestão (contas correntes, facturação, contabilidade, ...) em sistema de serviço via internet.

Este sistema, tem um comportamente relativamente próximo aos forms e subforms do ACCESS mas com base no MySQL. É aqui que o problema surge. Na edição de uma factura há um cabeçalho com os dados da factura (tabela facturas) e naturalmente um descritivo de linhas da factura (tabela linhas de factura); um dos campos do cabeçalho é o código de cliente e (sem estar a complicar mais) na tabela de linhas de factura um dos campos é a taxa de IVA que o artigo facturado vai ter para aquele cliente, por isto tive que criar uma tabela de taxas de IVA onde são relacionados os tipos de clientes com os tipos de artigos e que permite obter a taxa de IVA para esse artigo e cliente.

Até aqui tudo bem, um trigger que alterasse as taxas de IVA nas linhas de factura quando houvesse uma alteração no cliente da factura é fácil, o problema surge porque a tabela facturas tem um campo que é a soma das linhas de factura também actualizado por outro trigger despoletado quando é lançada uma nova linha na factura ou é alterada. Assim entro num ciclo infinito de upgrades entre as duas tabelas (facturas e linhas de factura). Isto complica-se porque se o sistema aceita triggers escritos manualmente mas também permite definir campos nas tabelas que podem ser a soma de um campo de outra tabela, é o caso do total de factura que vai ser alterado pelos totais das linhas de factura, então, ao definir o campo total de factura como a soma do total de linhas daquela factura o sistema cria automaticamente os triggers de inserssão, edição e eliminação de linhas de factura que interagem com o campo total de factura na tabela de facturas (funcionando em multi-trigger), uma vez que ao editar uma factura, naturalmente interessa que essa factura seja lançada automaticamente nas tabelas da contabilidade.

Assim, interessa-me que os triggers despoletem outros triggers mas neste caso (facturas, linhas de factura) tenho que dar um fim ao ciclo de triggers, ou testo se o valor a alterar é diferente do valor residente no campo ou alternativamente simplesmente bloqueio a edição do cabeçalho da factura apenas uma linha é inserida. Foi na primeira opção que a sua ajuda foi importamnte ao indicar que podia sempre quebrar o ciclo com o break quando o novo valor fosse igual ao antigo.

 

Resultado, estou metido numa camisa de 111 varas mas vou até ao fim.