Mto obrigado Chiappa, Com essa explicação agora entendi certinho como fazer e pra que serve. Eu to usando o Oracle 11g, em uma Maquina Virtual com Enterprise Linux 5, pra estudar. Mto obrigado pela ajuda.
Em 18 de setembro de 2012 18:53, J. Laurindo Chiappa <jlchia...@yahoo.com.br > escreveu: > ** > > > Miltão, ele não diz mas SUPONDO que a tal tabela EMPLOYEE é a mesma usada > para demonstrações a info sobre o salário do Gerente está em outro registro > dessa MESMA tabela, então vai dar MUTATING se ele tentar fazer isso num > trigger, okdoc ? > > Colega, antes de responder a sua pergunta sobre PL/SQL, fique Registrado > que triggers muitas vezes *** Não São *** a melhor maneira de se fazer > integridade de dados num ambiente Produção, pois : > > a) podem ser bypassadas por algumas tools de carga, e/ou em algumas > situações impedir o funcionamento adequado de algumas tools (que tentem > fazer direct path, por exemplo) > > b) podem interferir (às vezes seriamente) com a performance, já que (entre > outras coisas) disparam uma vez a cada INSERT (imagine o overhead num > ambiente com milhares de INSERTs ocorrendo) , não são parte do kernel do > banco (são um elemento Externo, não escrito em C e sem possibilidade de > usar ganchos e sub-rotinas internas do TRDBMS > > c) demandam Manutenção - natural, já que são construtos escritos por vc > > d) podem ter Diversos efeitos colaterais não previstos, vide > http://www.oracle.com/technetwork/issue-archive/2008/08-sep/o58asktom-101055.html > > ==>> então Recursos nativos do database - como índices de função, > constraints (seja em view materializadas seja em tabelas reais mesmo) e > relacionados - deveriam ser considerados em primeiro lugar, okdoc ? Isso > MESMO que alterações de modelagem sejam necessárias, tipo se adicionar no > registro da tabela de empregados uma coluna oculta MGR_SAL que contém o > salário do Gerente desse empregado, ter uma view materializada que > "replica" a informação do salário do gerente para cada empregado, ou qquer > coisa do tipo ... No caso específico de integridade de dados entre linhas > diferentes da tabela (o que é o seu caso, aqui) Tem Autores que até > defendem um outro approach : simplesmente REMOVER a permissão de INSERT > nessa tabela e/ou UPDATE nessa coluna SALARIO e dar pra todos os > interessados permissão de EXECUTE numa procedure ou função que vc escreveu > e que faz todas as checagens antes de alterar o dado na tabela .... É outro > ponto a considerar - não deixe de ler sobre essas possibilidades em > http://asktom.oracle.com/pls/apex/f?p=100:11:0::::P11_QUESTION_ID:698031000346429496, > http://asktom.oracle.com/pls/apex/f?p=100:11:0::::P11_QUESTION_ID:636506144470e > http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:4233459000346171405.... > > Vou responder as suas perguntas em um senso acadêmico, pra vc aprender, > mas fique Ciente das questões acima quando vc for programar/usar um RDBMS > Oracle "de verdade", right ? > > Isso dito, as suas Respostas: > > 1. como creio que vc já sabe, para proteção / integridade de dados o RDBMS > não permite que vc faça nem SELECTs na tabela quando há alterações > pendentes (o que é o caso da trigger BEFORE), sob pena de erro MUTATING > TABLE - não há como fazer isso na sua lógica, que usa justamente uma > trigger BEFORE INSERT na tabela employees e o registro do gerente a obter o > salário Também está na employees....Vc não diz mas Entendo que é esse o seu > problema/dúvida aqui... > > Assim, para contornar isso SEM usar as opções melhores que citei lá no > começo, vc poderia : > > - usar uma transação Autônoma que busque a info > > e/ou > > - ter uma trigger AFTER, que dispara após a inserção/alteração > > e/ou > > - SE a sua versão é 11g (o que vc não diz mas deveria, é SEMPRE > aconselhável citar a versão) vc poderia talvez usar copound triggers, veja > http://mikesmithers.wordpress.com/2010/04/24/compound-triggers-%E2%80%93-managing-the-mutant-menace/ > > 2. sobe a Exception, não : vc Não Pode usar uma Exception para "mostrar" > nada em princípio : o que uma EXCEPTION faz é desviar o fluxo do seu > programa quando há um erro, mas por si só ela NÃO implica em "mensagem" > alguma, nem em Abort do fluxo PL/SQL, nem em "aviso" algum, ok ? Vc até > poderia na área de EXCEPTION usar um comando apropriado (e inclusive Se vc > quer que o cliente que dez o SQL receba um warning E também que o SQL seja > abortado/sinalizado com erro, RAISE_APPLICATION_ERROR é a opção), mas não é > de forma alguma Obrigatório o EXCEPTION.... > > []s > > Chiappa > > > --- Em oracle_br@yahoogrupos.com.br, "Milton Bastos Henriquis Jr." > <miltonbastos@...> escreveu > > > > Boa tarde! > > > > Suas perguntas já estão todas respondidas por você mesmo... rs.... > > Está tudo correto o que vc falou. > > > > Faça um SELECT INTO para pegar o valor do salário do gerente > > do sujeito e armazenar numa variável. > > Depois compare o valor do salário do sujeito com a variável... > > Se for maior, vc dispara a exceção. > > > > > > > > > > 2012/9/18 Antony Ferreira <tonyferreira3@...> > > > > > ** > > > > > > > > > Boa tarde pessoal, > > > > > > Estou começando a estudar um pouco de PL/SQL e me surgiu umas duvidas. > > > Tenho a seguinte trigger: > > > > > > CREATE OR REPLACE TRIGGER imp_novos_emp > > > BEFORE INSERT OR UPDATE ON employees > > > FOR EACH ROW > > > BEGIN > > > IF NOT (:NEW.job_id IN ('AD_PRES', 'AD_VP')) THEN > > > IF :NEW.salary > 15000 THEN > > > RAISE_APPLICATION_ERROR (-20202,'Este empregado não pode receber este > > > valor'); > > > END IF; > > > END IF; > > > END imp_novos_emp; > > > / > > > > > > Qual seria a melhor maneira para eu poder impedir que seja inserido um > novo > > > empregado que tenha o salario maior que o gerente. > > > > > > Eu teria que fazer uma consulta na coluna manager_id da tabela > employees e > > > verificar se o salario do empregado que eu estou add é maior que o do > > > gerente? > > > Outra duvida, posso colocar uma excessão para mostrar que o salario é > > > invalido quando o salario do empregado que eu estou add é maior que o > do > > > gerente? > > > > > > [As partes desta mensagem que não continham texto foram removidas] > > > > > > > > > > > > > > > > > -- > > Att, > > > > > > [As partes desta mensagem que não continham texto foram removidas] > > > > > [As partes desta mensagem que não continham texto foram removidas] ------------------------------------ -------------------------------------------------------------------------------------------------------------------------- >Atenção! As mensagens do grupo ORACLE_BR são de acesso público e de inteira >responsabilidade de seus remetentes. Acesse: http://www.mail-archive.com/oracle_br@yahoogrupos.com.br/ -------------------------------------------------------------------------------------------------------------------------- >Apostilas » Dicas e Exemplos » Função » Mundo Oracle » Package » Procedure » >Scripts » Tutoriais - O GRUPO ORACLE_BR TEM SEU PROPRIO ESPAÇO! VISITE: >http://www.oraclebr.com.br/ ------------------------------------------------------------------------------------------------------------------------ Links do Yahoo! Grupos <*> Para visitar o site do seu grupo na web, acesse: http://br.groups.yahoo.com/group/oracle_br/ <*> Para sair deste grupo, envie um e-mail para: oracle_br-unsubscr...@yahoogrupos.com.br <*> O uso que você faz do Yahoo! Grupos está sujeito aos: http://br.yahoo.com/info/utos.html
