okdoc... Na verdade, enquanto especialista em tecnologia de RDBMS Oracle, o nosso trabalho é Alertar o cliente sobre os eventuais desdobramentos das opções escolhidas : se realmente, após vc explicar bem as restrições do solução programada (tal como mais código a manter, aus~encia de controle transacional, mais dificuldades referentes à multi-usuário e rollback de usuários, enfim, tudo o que foi dito), ainda assim o Cliente optar por assumir os riscos e fazer assim, vc cumpriu a obrigação, lava as mãos e faz como ele quer, só tomando o cuidado de Registrar por escrito (num e-mail, que seja) que se está seguindo por um caminho que pode não ser o mais recomendado, se der problema no futuro vc tem com o que se escudar...
[]s Chiappa --- Em oracle_br@yahoogrupos.com.br, "Giovanni Ferreira de Sousa" <giovanni.sousa@...> escreveu > > Valeu pelas dicas, Paulo e Chiappa... > > Vou conversar com o cliente, mais uma vez...embora ele esteja irredutível em > relação à utilização das TRIGGER... > > Um 2012 repleto de realizações e conquistas.... > > Abraços > > Giovanni. > > ________________________________ > > De: oracle_br@yahoogrupos.com.br em nome de José Laurindo > Enviada: qui 29/12/2011 18:55 > Para: oracle_br@yahoogrupos.com.br > Assunto: [oracle_br] Re: Tratamento de logs > > > > > Yep .... Na verdade eu aproveitei o gancho pra discutir um pouco de postura > técnica com o cliente, de detalhes como programação defensiva (aonde o cara > pensou ao menos um pouco sobre controle de transação, sobre o que acontece se > tiver um rollback inesperado, se tiver multi-usuários acessando o mesmo > recurso, etc), espero que tenha sido útil lá pro colega ... > Sobre a exception, realmente não vi o primeiro e-mail, mas se tá lá blz, fica > a recomendação, junto com todas as outras feitas na thread, para caso o > colega lá acabe optando por audit só dentro da proc dele... > > []s > > Chiappa > > --- Em oracle_br@yahoogrupos.com.br <mailto:oracle_br%40yahoogrupos.com.br> , > Paulo Petruzalek <ppetruzalek@> escreveu > > > > Concordo com tudo que você disse Chiappa, justamente por isso que reforcei > > na minha mensagem que estou só mostrando como fazer, não que eu concordo > > com a forma de ser feita. Eu coloquei a questão das exceptions no meu > > primeiro e-mail, o segundo que você respondeu foi só uma correção para > > citar os savepoints. > > > > De qualquer forma a solução por triggers certamente é a mais indicada... e > > se eles não dispõem de um dba para controlar isso, a base deles já está > > correndo o risco de dar todo tipo de problemas muito antes de que alguém > > reclame de uma trigger inválida... > > > > []'s > > > > Paulo > > > > --- Em qui, 29/12/11, José Laurindo <jlchiappa@> escreveu: > > > > > > De: José Laurindo <jlchiappa@> > > Assunto: [oracle_br] Re: Tratamento de logs > > Para: oracle_br@yahoogrupos.com.br <mailto:oracle_br%40yahoogrupos.com.br> > > Data: Quinta-feira, 29 de Dezembro de 2011, 11:06 > > > > > > Paulo, é absolutamente verdade que a maneira de desfazer apenas parte dos > > comandos da transação é o SAVEPOINT - no caso em questão, porém, uma > > solução procedural, além de ser mais longa, só vai ser disparada (óbvio) > > quando da execução do PL/SQL, se outras rotinas/programas fizerem DELETEs > > na tabela esses DELETEs passam SEM LOGS, e uma Auditoria em princípio deve > > pegar TODOS os DMLs, independente de onde venham... Outra coisa é que o > > %rowcount pega os casos de delete que não encontrou dados, MAS casos de > > erro efetivo no DELETE (por exemplo, tentativa de eliminar PK com filhos > > presentes) ele não pega, faltaria adicionar os EXCEPTIONS... > > > > Juntando isso com a necessidade (estranha, mas é um dado do problema) de > > só auditar DELETEs bem-sucedidos, eu optaria por um TRIGGER DE DML, assim : > > > > create or replace trigger TRG_AUD_DEL after DELETE on nomedatabela > > FOR EACH ROW > > BEGIN > > insert into tabeladelog(coluna1, coluna2, ... colunaN) > > values(:old.coluna1, :old.coluna2, ... :old.colunaN); > > END; > > > > ==> aí, além do código ser menor, a "auditoria" vai pegar QUALQUER DELETE > > na tabela, seja ou não vindo do PL/SQL, como a trigger é AFTER (depois, em > > inglês), ela automagicamente só dispara ** DEPOIS ** de um DELETE bem > > sucedido, aí vc não precisa se preocupar no seu código de auditoria com > > COMMITs/ROLLBACKs e ainda é transacional, ie, se depois do delete feito OK > > alguém pedir ROLLBACK do DELETE a inserção na tabela de log não é > > registrada - o colega não diz se isso é preciso mas pelo jeitão parece que > > sim ... > > > > Aliás, Giovani, coisas do tipo (ah, o que deve ser logado / o que deve > > ocorrer ocorre se neguinho pedir ROLLBACK de um DELETE bem-sucedido, o que > > deve ocorrer se alguém fazer DELETE fora do seu programa, o que deve > > ocorrer se duas sessões pedirem DELETE do mesmo registro , etc, etc) é > > nossa parte, enquanto técnicos especialistas em banco de dados, ter bem > > claro : o seu Cliente com quase 100% de certeza não faz a MENOR IDÉIA > > dessas coisas, nem imagina que o banco é MULTI-USUÁRIO, que podem haver > > erros de DELETE , etc, então quando ele te pede "ah, me faz um log", é um > > des-serviço vc não o avisar dessas coisas , não esclarecer bem a > > necessidade, o que ele quer que aconteça em cada caso ... > > > > []s > > > > Chiappa > > > > > > --- Em oracle_br@yahoogrupos.com.br <mailto:oracle_br%40yahoogrupos.com.br> > > , Paulo Petruzalek <ppetruzalek@> escreveu > > > > > > Complementando: acabei deixando na pressa o commit fora do if: > > > > > > If sql%rowcount = 0 then > > > rollback; > > > else > > > commit; > > > end if; > > > > > > Mas uma solução sem commits (dentro da sp) pode ser obtida com savepoints: > > > > > > begin > > > savepoint A; > > > insert into ... > > > delete from ... > > > if sql%rowcount = 0 then > > > rollback to A; > > > end if; > > > end; > > > / > > > > > > Neste caso o controle da transação ficará por conta do código chamador, > > > sem o risco de commitar algo que não devia. > > > > > > Paulo > > > > > > --- Em qua, 28/12/11, Paulo Petruzalek <ppetruzalek@> escreveu: > > > > > > De: Paulo Petruzalek <ppetruzalek@> > > > Assunto: Re: [oracle_br] Tratamento de logs > > > Para: oracle_br@yahoogrupos.com.br > > > <mailto:oracle_br%40yahoogrupos.com.br> > > > Data: Quarta-feira, 28 de Dezembro de 2011, 22:27 > > > > > > Se for para tratar o caso de onde o delete não ocorre, basta fazer um: > > > > > > if sql%rowcount = 0 then > > > rollback; > > > end if; > > > > > > Agora no caso de "dar pau", você vai ter que instrumentar o código com um > > > bloco exception. Exemplo simplificado: > > > > > > begin > > > insert into log values (...) ; > > > delete from tabela where x = ...; > > > if sql%rowcount = 0 then rollback; > > > end if; > > > commit; > > > > > > exeception > > > when others then rollback; > > > end; > > > / > > > > > > Talvez seja mais elegante declarar uma exceção e lançar ela no caso do > > > sql%rowcount ser igual a 0... mas enfim, o estilo de código fica por sua > > > conta e/ou pelas regras do seu projeto. > > > > > > Também note que deixar controle de transações (commit / rollback) dentro > > > de uma sp pode causar muitos problemas se esta for chamada por outras > > > sps. Eu não necessariamente usaria esta abordagem, só fiz o exemplo assim > > > para ficar compatível com o seu código. > > > > > > Paulo > > > > > > --- Em qua, 28/12/11, Giovanni Ferreira de Sousa <giovanni.sousa@> > > > escreveu: > > > > > > De: Giovanni Ferreira de Sousa <giovanni.sousa@> > > > Assunto: [oracle_br] Tratamento de logs > > > Para: oracle_br@yahoogrupos.com.br > > > <mailto:oracle_br%40yahoogrupos.com.br> > > > Data: Quarta-feira, 28 de Dezembro de 2011, 10:56 > > > > > > Bom Dia galera, > > > > > > > > > Estou com a seguinte situação aqui no trabalho: > > > > > > Um usuário solicitou que para as deleções físicas no banco, esses > > > registros deletado deveriam ser armazendos em uma tabela de log. No > > > schema da aplicação existe uma procedure que faz o delete nas tabelas. > > > Para atender a demanda do usuário foi adicionado na procedure o insert na > > > tabela de log, baseado no registro que será deletado, como segue no > > > exemplo abaixo. Sendo assim gostaria da ajuda de vocês para o seguinte: > > > > > > Após o INSERT é feito o DELETE. > > > > > > SE o DELETE der PAU ou não for feito. Como faço pra dar ROLLBACK(no > > > INSERT anterior)? > > > > > > > > > > > > CREATE OR REPLACE PROCEDURE DBSISMAC.sp_solicitacao_remanej_final ( > > > estado IN NUMBER, > > > usuario IN NUMBER, > > > competencia IN NUMBER, > > > DS_USERNAME IN VARCHAR2) > > > IS > > > BEGIN > > > INSERT INTO DBSISMAC.TL_TMQUADRO_06 > > > SELECT competencia AS NU_COMPETENCIA_SOLICITACAO, > > > CO_GESTAO, > > > CO_MUNICIPIO_IBGE, > > > CO_CNES, > > > NO_UNIDADE, > > > NU_CONTRATO, > > > DT_PUBLIC_EXT_CONTRATO, > > > VL_TOTAL_FNS, > > > CO_PROTOCOLO, > > > CO_USUARIO, > > > DT_ALTERACAO, > > > DS_USERNAME AS DS_USERNAME, > > > 'EXCLUÍDO' AS DS_OPERACAO, > > > SYSDATE AS DT_OPERACAO > > > FROM DBSISMAC.TM_QUADRO_06 > > > WHERE SUBSTR (CO_MUNICIPIO_IBGE, 0, 2) = estado; > > > > > > DELETE FROM DBSISMAC.TM_QUADRO_06 > > > WHERE SUBSTR (CO_MUNICIPIO_IBGE, 0, 2) = estado; > > > COMMIT; > > > END; > > > / > > > > > > Atenciosamente, > > > > > > Giovanni > > > > > > > > > [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 > > > > > > > > > > > > > > > [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 > > > > > > > > > > > > > > > [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 > > > > > > > > > > [As partes desta mensagem que não continham texto foram removidas] > > > > > > > > > [As partes desta mensagem que não continham texto foram removidas] >
