4D v16.3Triggers |
||
|
4D v16.3
Triggers
Triggers
Um trigger é um método associado a uma tabela. É uma propriedade de uma tabela. Você não chama aos triggers; os triggers são chamados automaticamente pelo motor de 4D cada vez que manipular registros da tabela (adição, eliminação, modificação, carregar). Pode escrever triggers muito simples, e depois fazê-los mais sofisticados. Os triggers podem evitar operações "ilegais" nos registros de seu banco. São uma ferramenta muito poderosa que permite controlar as operações em tabelas, além de evitar perdas de dados acidentalmente. Por exemplo, em um sistema de faturação, pode evitar que um usuário crie uma fatura sem especificar o cliente que deve ser faturado. Nota: Veja o Guia de segurança 4D para uma visão geral das propriedades de segurança de 4D. Por padrão, quando cria uma tabela no ambiente Desenho, a tabela não tem trigger. Para utilizar um trigger para uma tabela, necessita:
Ativar um trigger que não esteja escrito ou escrever um trigger sem ativá-lo não afeta as operações realizadas em uma tabela. Para ativar um trigger, selecione as opções Triggers para a tabela na janela de propriedades da tabela: Se essa opção for selecionada, o trigger será chamado cada vez que um registro da tabela seja modificado.
[minhaTabela]meuCampo:=[minhaTabela]meuCampo Se esta opção for selecionada, o trigger será chamado cada vez que um registro da tabela seja apagado, ou seja nas seguintes circunstâncias:
Nota: o comando APPLY TO SELECTION NÃO chama ao trigger. Se esta opção for selecionada, o trigger será chamado todas as vezes que um registro for criado na tabela, ou seja nas seguintes circunstâncias:
Para criar um trigger para uma tabela, utilize a janela de propriedades da tabela, clique no botão Editar ou pressione Alt (em Windows) ou Opção (Macintosh) e duplo clique na tabela na janela de estrutura. Para maior informação, consulte o manual de Desenho de 4D. Um trigger pode ser chamado por um dos quatro eventos de banco descritos anteriormente. No trigger, pode detectar que evento está ocorrendo chamando a função Trigger event. Esta função retorna um valor numérico que indica o evento do banco. ` Trigger for [umaTabela] Um trigger tem dois propósitos:
Cada vez que um registro for salvado (adicionado ou modificado) a uma tabela [Documentos], você deseja “marcar” o registro com os marcadores de criação e modificação. Pode escrever o seguinte trigger:` Trigger para tabla [Documentos] Case of Nota: a função Time stamp utilizada neste exemplo é um pequeno método de projeto que retorna o número de segundos transcorridos desde uma data escolhida arbitrariamente. Nota: ver o exemplo do comando GET DOCUMENT PROPERTIES para uma análise completa deste exemplo. Para aceitar ou recusar uma operação do banco de dados, o trigger deve retornar um código de erro de trigger no resultado da função $0. Imaginemos o caso de uma tabela [Empregados]. Durante a entrada de dados, você controla o campo [Empregados]Numero_Segurança_Social. Quando o usuário clicar no botão de validação, você verifica o campo utilizando o método de objeto do botão: ` Método de objeto bAccept Se o valor do campo for correto, aceita a entrada de dados; se o valor do campo não for correto, mostra um alerta e permanece em entrada de dados. ` Extração de um método de projeto Utilizando um trigger para a tabela [Empregados], pode implementar a regra [Empregados]Numero_Segurança_Social em todos os níveis do banco. O trigger seria assim: ` Trigger for [Empregados] Da mesma forma, se um plug-in 4D tentar guardar um registro em [Empregados] com um número de segurança social incorreto, o trigger gerará o mesmo erro e o registro não são guardadas. Note que mesmo que não tiver um trigger para uma tabela, o banco pode devolver erros quando tentar guardar ou apagar um registro. Por exemplo, se tentar salvar um registro com um valor duplicado em um campo indexado único, se retorna o erro -9998.
A nível do processo, você administra os erros trigger da mesma maneira que os erros de motor de banco de dados:
Os triggers funcionam ao nível do motor da banco de dados. Este ponto se resume no seguinte diagrama:
Note que se você usar o sistema 4D senha, você pode executar o comando Current user no trigger para, por exemplo, para salvar o nome do usuário na origem da trigger chamada em uma tabela com a história, mesmo em modo cliente-servidor. As transações devem ser administradas ao nível do processo chamador. Não podem ser administrados ao nível do trigger. Se durante a execução do trigger, tiver que adicionar, modificar ou apagar vários registros (ver o estudo de caso a seguir), primeiro deve utilizar o comando In transaction desde o trigger para testar se o processo chamante está em transação atualmente. Se não for o caso, o trigger poderia ser encontrado com um registro bloqueado. Portanto, se o processo chamador não estiver em transação, nem comece as operações nos registros e retorna um erro em $0 para indicar ao processo chamador que a operação do banco de dados deve ser executada em uma transação. Por outro lado, se encontrar registros bloqueados, o processo chamante não poderá desfazer as ações do trigger. Dada a seguinte estrutura de exemplo: Para conservar a integridade relacional dos dados, a eliminação de uma fatura exige as seguintes ações de parte do trigger de [Faturas]:
Primeiro, o trigger de [Faturas] deve realizar estas ações apenas se o processo chamador estiver em transação, de maneira que seja possível desfazer em caso de encontrar um registro bloqueado. Segundo, o trigger de [Linha_Fatura] está em cascata com o trigger de [Faturas]. O trigger [Linha_Fatura] é executado "dentro" da execução do trigger [Faturas], porque a eliminação dos elementos da lista é consecutiva a uma chamada a DELETE SELECTION desde o trigger de [Faturas].Imagine que todas as tabelas neste exemplo tem triggers ativados para todos os eventos da banco de dados. A cascata de triggers será: O trigger de [Faturas] é chamado porque o processo chamador apaga uma fatura O trigger de [Clientes] é chamado porque o trigger de [Faturas] trigger atualiza o campo Vendas_Brutas O trigger de [Linha_Fatura] é chamado porque o trigger [Faturas] apaga uma linha (repetida) O trigger de [Produtos] é chamado porque o trigger de [Linha_Fatura] atualiza o campo Quantidade_Vendida O trigger de [Pagamentos] é chamado porque o trigger de [Faturas] apaga um pagamento (repetido) Nesta cascata, o trigger de [Faturas] é executado no nível 1, os triggers de [Clientes], [Linha_Fatura], e [Pagamentos] no nível 2 e o trigger de [Produtos] no nível 3. De dentro dos triggers, é possível utilizar o comando Trigger level para detectar o nível no qual é executado um trigger. Além disso, pode utilizar o comando TRIGGER PROPERTIES para obter informação sobre os outros níveis. Por exemplo, um registro de [Produtos] é apagado a nível do processo, o trigger de [Produtos] será executado no nível 1, e não no nível 3. Com Trigger level e TRIGGER PROPERTIES, pode identificar a causa de uma ação. Em nosso exemplo, uma fatura se apaga ao nível do processo. Se apagarmos um registro de [Clientes] ao nível do processo, o trigger de [Clientes] deve tentar apagar todas as faturas relacionadas com esse cliente. Isso significa que o trigger [Faturas] será chamado como no exemplo acima, mas por outra razão. Desde o trigger de [Faturas], pode detectar se foi executada no nível 1 ou 2. Se tiver sido executado no nível 2, pode verificar se foi porque o registro de [Clientes] foi apagado. Se este for o caso, não precisa se preocupar com atualizar o campo Vendas_Brutas.
Ver também
Métodos
|
PROPRIEDADES
Produto: 4D
HISTÓRIA
ARTICLE USAGE
Manual de linguagem 4D ( 4D v16) |