Oi, tudo jóia ? Eu havia dado uma resposta (que vc provavelmente até já viu) num outro fórum mas se vc não se importar, vou colar aqui a mesma resposta - não só para que outras pessoas que precisem tenham outra chance de encontrar MAS também para ter outra chance de provocar eventuais respostas, outros pontos de vistas e outras Possibilidades que não me ocorreram : entre outras coisas, esse tipo de aprendizado/troca de idéias para que eu tenha crescimento profissional (já que essa coisa de banco de dados é o que paga o leitinho das crianças) é uma das coisas que me move...
Então segue : bom, primeiro não entendi patavina sobre essa sua obs de "não é ambiente CGI" - o que que é isso no contexto de programação PL/SQL no database ?? Me parece ser algum conceito da tua linguagem/tool/ambiente de desenvolvimento... A próxima pergunta é a de sempre : PARA QUE vc quer saber o nome do PL/SQL em execução, é para fim de debug (ie, numa ÚNICA VEZ vc quer acompanhar o comportamento de rotinas PL/SQL, provavelmente para analisar algum erro lógico ?? Se é isso, considere a opção de ** DEBUGAR ** o PL/SQL, www.thatjeffsmith.com/archive/2014/02/ho...-the-plsql-debugger/ exemplifica : com esse recurso vc tem até mais recursos, podendo colocar BREAKPOINTs além de acompanhar linha a linha a execução.... A questão apenas é que para debugar PL/SQL no SQL Developer vc tem que estar executando o PL/SQL em questão a partir do SQL developer, nem sempre isso é possível... Muitas vezes é totalmente possível vc levantar os parâmetros que estão sendo passados e executar o PL/SQL em questão manualmente no SQL developer informando esses parâmetros, mas às vezes não é.... Aí finalmente a sua Resposta : se ainda não sabia, *** SAIBA *** que a linguagem PL/SQL absolutamente *** NÃO TEM NENHUM COMANDO PARA INTERAGIR COM TELA/FRONT-END *** : sendo a linguagem de programação back-end que é, o PL/SQL NÂO tem comando para print de texto, NÃO tem comando pra criar uma janela, NÃO tem comando para receber input via teclado do usuário, NÃO tem comando pra interagir com mouse ou impressora.... PL/SQL é uma linguagem feita para manipular (com extrema eficiência) dados dentro do banco de dados, NADA MAIS que isso.... Nesse contexto, o que o DBMS_OUTPUT faz NÂO É imprimir coisa NENHUMA, é simplesmente colocar uma string num buffer, e Alguns ambientes capazes de executar rotinas PL/SQL (como o sqlplus) foram programados para reconhecer e exibir o conteúdo desse buffer... Yes ??? Então se a tua linguagem/ambiente/tool de programação de onde vc tá chamando o PL/SQL não exibe nada, COM CERTEZA ela simplesmente Não Foi Programada para reconhecer e exibir o conteúdo do buffer.... Tá claro ? É alguma coisa EXTERNA ao PL/SQL e que o PL/SQL Não Tem Como interferir... Porém antes de desistir Tenha ** certeza ** que a sua tool/linguagem de programação Realmente Não Foi programada para reconhecer o buffer do DBMS_OUTPUT (** muitas ** tem esse Suporte mas simplesmente não está Ativado), e se tiver Dúvidas sobre isso numa outra mensagem *** DETALHE EXATAMENTE ** qual é essa tool/linguagem/ambiente de programação que vc está usando, que eventualmente quem trabalhar com ela/a conhecer pode palpitar : por exemplo, APEX rodando num web browser em princípio não tem esse Suporte built-in mas http://oraclequirks.blogspot.com.br/2007/08/practical-example-of-using-global.html exemplifica como se ler o conteúdo do buffer do DBMS_OUTPUT, persistir numa GTT e aí é trivial fazer um select na GTT dentro da aplicação... Registro aqui, em AINDA OUTRA variação possível, que desde muito tempo nós sempre tivemos a chance de chamar de dentro do PL/SQL rotinas feitas em linguagens que tem acesso ao hardware/periféricos como exibição em tela, impressoras e quetais : duas das mais comuns são C (via EXTERNAL PROCEDURES) e Java (via JVM interna no RDBMS Oracle, se disponível na sua instalação) : não vou usar esse recurso, entre outras questões porque ele demanda Conhecimento e Pesquisa, mas fica a Possibilidade... O que vc pode fazer num caso onde o buffer do DBMS_OUTPUT não tá sendo reconhecido/impresso pela tua tool/ambiente que chama a rotina PL/SQL E não é viável debugar no SQL Developer ou similares é : a) o MAIS ÓBVIO, instrumentar o teu programa que vai chamar as rotinas PL/SQL para imprimir o nome da rotina que vai chamar : por exemplo, se fosse um programa C poderia ser algo do tipo : .... printf('Vou chamar a rotina nomedapackage.proc1'); exec nomedapackage.proc1(); printf('Vou Chamar a rotina nomedapackage.proc2'); exec nomedapackage.proc2(); .... (Como eu disse acima, é TOTALMENTE PARTE DA ARQUITETURA proposta vc desenvolver front-end em alguma outra linguagem/tool E desenvolver o back-end/manipulação de dados em PL/SQL que será chamado pelo front-end : justamente por isso a Oracle sempre primou por disponibilizar acesso à rotinas PL/SQL stored para o mais amplo espectro de linguagem/ambientes)... Uma variação do tema é vc acionar o PL/SQL profiler , veja oracle-base.com/articles/11g/plsql-hierarchical-profiler-11gr1 para exemplo OU b) instrumentar o PL/SQL para que ele mande uma mensagem assim que começar a rotina : como vc tentou fazer com dbms_output e não conseguiu, outra opção pra isso seria vc colocar uma mensagem curta na coluna CLIENT_INFO da view interna V$SESSION (essa coluna é reservada para isso) e aí a tua aplicação abre uma nova janela, conecta no banco e fica fazendo pooling nessa view interna e imprime o conteúdo da coluna : www.toadworld.com/platforms/oracle/w/wik...info-set-client-info é um exemplo de uso da DBMS_APPLICATION, que é a built-in que vc usaria nas suas rotinas PL/SQL OU c) se vc quer saber o nome da rotina que está sendo executada ** SEM ** intrumentar nada, ie, sem escrever nada/sem alterar nem a sua aplicação nem as suas rotinas PL/SQL, a opção seria acompanhar a execução pelas views X$ internas : em asktom.oracle.com/pls/asktom/f?p=100:11:...tion_id:767025833873 eu dou um exemplo... []s Chiappa OBS : há sempre a possibilidade de vc obter a lista de rotinas executadas post-mortem, após a execução, via TRACE : entendo que não é isso que vc quer, mas lembremos que existe a possibilidade...
