Bom, antes de responder uma obs importante : tou vendo que vc está programando
nalguma GUI , tipo Oracle Forms, VB, Delphi ou coisa assim, aonde os dados são
trazidos do db, o processamento ocorre primeiro na máquina-cliente e depois
quando o usuário clicka nalgum botão de COMMIT aí sim é que o banco é acionado
e recebe as eventuais alterações de dados... Tá ** MEGA CLARO ** que uma
trigger de database , sendo assim, normalmente só vai disparar quando o tal
botão de commit for acionado, yep ??? E mais, os dados alterados no banco
normalmente só vai refletir na tela após algum tipo de comando de REFRESH, blz
??? Veja lá se de repente a trigger já não está disparando e fazendo o UPDATE,
certinho, mas falta o comando de refresh/requery na sua tool pra trazer o dado
alterado.....
Outra coisa, vejo que vc está ** sempre ** fazendo UPDATE apenas na tabela
est_itensdeestoque : vc tem CERTEZA de que realmente rigorosamente TODOS os
registros presentes na est_cadmaterial estão presentes TAMBÉM na
est_itensdeestoque, de modo que SEMPRE seja o caso de só fazer um UPDATE ????
Mesmo ??? Pergunto isso porque, como sabemos, um UPDATE que não encontre
registro nenhum **** NÃO É ***** considerado erro, o RDBMS rigorosamente Não
vai te dar mensagem NENHUMA, okdoc ??
E é claro, não tem a ver com a pergunta mas eu ** questiono ** a sua
modelagem de ter uma tabela à parte : não seria um caso de ter a flag
necessária na própria tabela-origem, e (se preciso) ter um índice de função que
indexe só os registros ativos ?
Isso posto, se o acima exposto não for cabível - não vejo nenhum erro per se
no trigger, é mesmo fazer o DEBUG completo da tua lógica, principalmente
checando as colunas-chave (principalmente essa coluna CODIGOMATINT, recheque
que o teu UPDATE está corretamente acessando apenas e tão somente a linha
certa, que os dados presentes ESTÃO gravados corretamente, etc), procurando por
outras triggers, confirmando datatypes... Eu me preocuparia MUITO também com
eventuais conflitos, tipo um outro usuário já estar alterando o registro que a
trigger vai ter que acessar, coisas assim...
Abaixo veja o exemplo :
SQL> create table est_cadmaterial(
CODIGOMATINT number,
DESCRICAO varchar2(40),
gerarateiomat char(1) );
create table est_itensdeestoque (
CODIGOMATINT number,
bloqueiamovtorateio char(1)
);
2 3 4
Table created.
SQL> SQL> 2 3 4
Table created.
SQL> create or replace TRIGGER TR_EST_BLOQUEIARATEIO
after insert or update on est_cadmaterial
for each row when (new.gerarateiomat = 'S')
BEGIN
if updating then
UPDATE est_itensdeestoque SET bloqueiamovtorateio = 'S' WHERE
CODIGOMATINT = :old.codigomatint;
else
UPDATE est_itensdeestoque SET bloqueiamovtorateio = 'S' WHERE
CODIGOMATINT = :new.codigomatint;
end if;
END;
2 3 4 5 6 7 8 9 10 11
12 /
Trigger created.
==> Inserção dos registros na tabela-histórico, assegurando-se que o UPDATE da
trigger vai funcionar :
SQL> insert into est_itensdeestoque values (1, 'N');
1 row created.
SQL> insert into est_itensdeestoque values (2, 'N');
1 row created.
SQL> commit;
Commit complete.
==> com os dados OK e presentes (E sem acesso concorrente, sem dados
duplicados, com chave de acesso correta, blablabla), a trigger vai funcionar
Perfeitamente :
SQL> insert into est_itensdeestoque values (1, 'N');
1 row created.
SQL> insert into est_itensdeestoque values (2, 'N');
1 row created.
SQL> commit;
Commit complete.
SQL> insert into est_cadmaterial values (1, 'Linha 1', 'N');
1 row created.
SQL> insert into est_cadmaterial values (2, 'LInha 2', 'S');
1 row created.
SQL> update est_cadmaterial set gerarateiomat = 'S' where CODIGOMATINT=1;
1 row updated.
SQL> select * from est_itensdeestoque ;
CODIGOMATINT B
------------ -
1 S
2 S
SQL>
[]s
Chiappa
