Colega, seguinte :
a) como já deve ter ficado Claro, o mecanismo do Forms é : quando vc faz uma
Modificação num item base-table, o Forms *** NÃO *** gera nem envia
imediatamente o DML correspondente pro database, ok ? Então ** NÃO TEM COMO **
vc "juntar" numa só Transação os DMLs feitos no banco (por uma trigger do
Forms, por uma procedure do Banco, etc) com os Futuros DMLs que serão gerados e
disparados pelo Forms em relação aos base-itens alterados quando o procedimento
de forms_commit for executado - é Óbvio que eles vão estar numa OUTRA
transação, yes ??
O que eu RECOMENDARIA nesse sentido é centralizar no database, ** NÂO **
alterando os itens base-table e sim AO INVÉS DISSO adicionar DMLs
correspondentes no código PL/SQL , aí sim tudo estará na mesma transação, que
AÍ SIM se sofrer um rollback tudo é desfeito, esse é o conceito mesmo de
Transação.... Claro, para que o usuário final veja na tela as alterações, no
final de todo o processamento vc inclui um código para refresh dos dados,
refazendo a query - afaik como esses procedimentos são Restritos, pode ser que
vc precise lançar mão de truques como usar um TIMER, mas isso é normal na
programação Forms client/server...
b) "Quanto a setar valores para itens de um bloco base-table, beleza, ele não
participa da transação, mas no caso de um rollback, ele deveria descartar as
alterações, não ?!?"
O parágrafo acima já esclareceu, mas a resposta é NÃO : como eu disse, quando
há um rollback (ou um COMMIT!!) no banco, é a Transação que está em execução NO
BANCO que vai ser encerrada ou desfeita, okdoc ??? Tá claro ?? SE vc quiser
"limpar" o status dos campos base-table alterados (como eu disse acima não
recomendo isso, Recomendo que as alterações sejam feitas NO DATABASE, mas
enfim) aí vc teria que usar uma built-in de limpeza, como CLEAR-qquercoisa...
E mais, no sentido contrário, no help mesmo do Forms para CLEAR_FORM nós temos
bem clara a observação :
"If you use a PL/SQL ROLLBACK statement in an anonymous block or a user-defined
subprogram, Form Builder interprets that statement as a CLEAR_FORM built-in
subprogram with no parameters. "
=> OU SEJA, o rollback num PL/SQL ** seu ** , dentro do Forms, VAI SER
SILENCIOSAMENTE TRANSFORMADO EM CLEAR_FORM, ** não ** indo para o database e
portanto ** não ** encerrando a transação porventura aberta NO DATABASE, yes ??
c) sim - veja o link que te passei na msg anterior, no processamento rotineiro
do Forms sim, qquer erro de database ORA-xxx (até mesmo um erro ORA-20xxx
levantado por um raise_application_error NO DATABASE) é detectado como erro, E
quem trata erros é a trigger ON-ERROR, sim...
[]s
Chiappa
--- Em oracle_br@yahoogrupos.com.br, Tiago de Assis Pimenta <tiagopimenta@...>
escreveu
>
> Bom dia pessal,
>
> - Eduardo -
>
> Vou aprofundar um pouco mais... tenho um botão que chama a procedure
> "PRC_CONC_ANALISE", logo no inicio dessa proc, tem um commit, depois tem
> algumas validações, uma parte que seta valores a determinados campos de um
> bloco baseado em tabela, outras proc's de validações e ai vem a parte parte
> que preciso commitar as alterações, essa parte basicamente chama uma proc de
> validação, commita, chama uma proc de impressão, da um go_item no botão de
> pesquisa e faz a pesquisa novamente com os valores atualizados. Abaixo está a
> parte que comentei agora:
>
> begin
> prc_libera;
> prc_commit;
> call_hc_print;
> go_item('BL_control.btn_pesquisa');
> execute_trigger('WHEN-BUTTON-PRESSED');
> exception
> when others then
> clear_form(full_rollback);
> execute_trigger('WHEN-NEW-FORM-INSTANCE');
> raise form_trigger_failure;
> end;
>
> Um teste que eu fiz, foi, antes do prc_libera ali, coloquei um raise
> form_trigger_failure, ai ele entra no exception. Mas simulando um erro a
> nível de banco (Trigger na tabela), não entra n exception, nem erro a nível
> de aplicação.
>
> - Chiappa -
>
> Sim sim, é em uma trigger da tabela, não descrevi que o
> raise_application_error estava em uma trigger, pois poderiam confundir com
> uma trigger do forms... Mas você entendeu corretamente, está numa trigger de
> uma tabela que faço uma atualização na aplicação.
>
> Tenho a proc chamada "PRC_CONC_ANALISE" e nela, as outras proc's que fazem
> validações e algumas dessas proc's de validações, tinha lá o commit
> encerrando a transação, ou seja, o processo era mais ou menos assim... Clico
> no botão, no when-button-pressed, chamo a "PRC_CONC_ANALISE"... nela seto um
> campo de determinado bloco, o status como "CONCLUIDO", commito, depois faço
> outras validações, seto um campo de outro bloco como "CONCLUIDO", mas em
> algum momento aqui (Não é sempre que acontece), ele dá um erro e não comita.
> Dai ficamos com o registro pai como Concluido e o filho como Aberto, ou seja,
> a integridade dos dados aqui foi pro espaço.
>
> Quanto a setar valores para itens de um bloco base-table, beleza, ele não
> participa da transação, mas no caso de um rollback, ele deveria descartar as
> alterações, não ?!? Vamos imaginas duas situações, eu seto valores para um
> item do bloco base-table, ai faço umas validações e seto valor para um item
> de outro bloco base-table, ai aqui dá um erro e não é possível setar os
> valores desse segundo bloco, como estou dentro de um begin/exception/end, e
> no exception tem um clear_form(full_rollback), ele deveria descartar a
> alteração do primeiro bloco, correto ? Segunda cituação, idem a anterior, só
> que em vez do erro fim da aplicação, vem do banco, teria que entrar no
> exception também e dar rollback, correto ?
>
> Quanto a terceira parte, então na teoria, um erro no banco, seria
> interpretado pela aplicação e eu conseguiria dar um rollback, certo ?
>
> [ ]s
>
>
> ________________________________
> De: J. Laurindo Chiappa <jlchiappa@...>
> Para: oracle_br@yahoogrupos.com.br
> Enviadas: Quinta-feira, 22 de Novembro de 2012 17:08
> Assunto: [oracle_br] Re: [Forms] "Controle de Transação"
>
>
>
> Bom, vamos por partes : primeiro absolutamente *** não existe ** isso de
> "raise_application_error em uma tabela", isso é Impossível, não faz
> sentido... RAISE_APPLICATION_ERROR é built-in ** PL/SQL **, então vc o coloca
> numa ROTINA PL/SQL, e nunca numa "tabela", okdoc ? Até pode ser que haja uma
> TRIGGER DE TABELA com o built-in, mas clarificando, é NA TRIGGER (que é uma
> rotina PL/SQL) que ele fica, yes ??
>
> Segundo : no RDBMS Oracle, uma TRANSAÇÃO ocorre automaticamente com o
> primeiro DML e fica ativa até receber um COMMIT ou um ROLLBACK - todos os
> DMLs que forem executados pela sessão após o início da transação vão ser
> PARTE dessa mesma e única Transação aberta, certo ? Isso posto, vc não
> explicita mas pelo que entendi em um (ou mais de um) trigger do Forms vc
> chama procedures PL/SQL, e havia COMMITs encerrando a transação (talvez em
> cada proc, fazendo na prática cada proc ter a sua própria transação separada,
> já que o primeiro DMLs da próxima proc abriria nova transação) E hoje o que
> vc quer é alterar o Form para que tudo ocorra na mesma transação, né ? => Se
> for mesmo isso, o procedimento é esse mesmo que vc fez, ie : retirar tudo que
> for COMMIT e ROLLBACK das procs (evitando que a transação aberta pelo
> primeiro DML da primeira proc seja fechada), sim.... Idealmente, se for
> possível vc ter um controle Centralizado (ie, uma
> proc EXEC_ROTINA a partir de onde vc chama uma por uma as outras procs
> todas) beleza, vc colocaria o COMMIT (ou ROLLBACK talvez, em caso de erro)
> nessa proc "central" que chama todas as outras, mas se não der aí sim, é ter
> o fecho da única transação aberta pelo primeiro DML da primeira proc sendo
> feito na ** última ** proc a ser executada - não entendi por que vc deixou
> COMMIT na primeira proc, se o que eu falei acima é o seu objetivo.... Será
> que essa primeira proc vai ser a sua "controladora" , tudo vai ser chamado
> por ela ? Se sim ok, vc está certo, se não, não faz sentido...
>
> Um ponto adicional : vc Sabe que quando vc altera valores em itens de um
> bloco base-table (imagino que é isso que vc quer dizer com "ele seta valores
> para o bloco baseado em tabela") o Forms *** não ** envia o INSERT ou UPDATE
> correspondente pro banco nesse instante, PORTANTO não abre transação ainda,
> certo ??? Apenas quando o usuário do Forms pressionar key-commit (ou clickar
> no botão de save, enfim) aí SIM é que o Forms vai gerar e enviar pro banco os
> INSERTs e UPDATEs necessários , yes ?? Então vc está Absolutamente Enganado
> se acha que as alterações feitas pelo seu PL/SQL em itens de blocos
> base-table tá participando de uma eventual Transação aberta por DMLs enviados
> pro banco por outras procs ou triggers , yep ???????
>
> Terceiro, sobre tratamento de erros : o ponto CRUCIAL a se colocar aqui
> (sendo Forms client/server, o que vc não diz mas IMAGINO ser o caso) é que se
> o PL/SQL em execução reside no Forms (ie, ele é uma procedure ou function ou
> trigger criada DENTRO DO FORMS) ela está sendo executada pelo interpretador
> PL/SQL DO FORMS, enquanto que uma rotina (seja proc, function,package ou
> trigger) criada no banco executa no interpretador PL/SQL DO DATABASE, yep ??
> Então um RAISE_APPLICATION_ERROR sinalizado pelo interpretador PL/SQL do
> forms não vai ser "enxergado" pelo do database... Já o contrário (ie, um
> RAISE_APPLICATION_ERROR disparado por uma rotina PL/SQL residente no
> database), apesar de não ser reconhecida pelo interpretador PL/SQL do Forms
> (que não faz idéia do que o interpretador PL/SQL do banco fez ou não), ela é
> SIM reconhecida pelo Forms, que vai disparar a trigger de erro
> correspondente, então vc pode capturar isso customizando a trigger
> genérica de erros do Forms, vide
> http://talk2gerd.blogspot.com.br/2006/12/best-practices-on-error-and-on-message.html
>
>
> []s
>
> Chiappa
>
>
> --- Em oracle_br@yahoogrupos.com.br, Tiago de Assis Pimenta <tiagopimenta@>
> escreveu
> >
> > Pessoal, boa tarde.
> >
> > Estou com uma tela aqui (forms) que preciso "controlar a transação" nele. O
> > forms tem bastante regras nas quais fica inviável a reconstrução dele. Em
> > um determinado processo nesse forms, é chamado outros processos (Proc's)
> > que fazem insert em banco, setam valores para blocos baseados em tabelas,
> > enfim, tem várias outras transações ocorrendo. Já olhei cada transação
> > procurando um commit e todos que achei eu desabilitei, deixando só no final
> > do primeiro processo, um commit e um exception caso de erro, o problema é
> > justamente o exception que não está "funcionando".
> >
> > Por exemplo, no momento que ele seta valores para o bloco baseado em
> > tabela, estava dando um erro que era porque o bloco estava setado como
> > insert/update/delete como false, ou seja, deu um erro, mas em vez de
> > acontecer o rollback dos outros processo, ele continuou como se não fosse
> > um erro.
> >
> > Outro erro que o exception do forms não "pegou", foi um
> > raise_application_error que coloquei na tabela direto no banco, parece que
> > para o forms, o raise no banco não é um exception.
> >
> > Então a minha primeira dúvida é a seguinte: Um raise direto na tabela no
> > banco realmente não é visto pelo forms como um erro ??
> >
> > A segunda dúvida é um pouco mais complicada, mas queria saber quais as
> > possibilidades, do erro no bloco baseado em tabela no forms, não ter sido
> > "pego" como um erro e não ter entrado no exception when others then !!!
> >
> > Att.
> >
> > Tiago Pimenta
> >
> > [As partes desta mensagem que não continham texto foram removidas]
> >
>
>
>
>
> [As partes desta mensagem que não continham texto foram removidas]
>
