Eduardo, só uma obs em cima : o que o Alessandro falou é *** muito ***, mas 
MUITO Sério, mesmo : a questão é que no RDBMS Oracle automagicamente um SELECT 
enxerga os dados *** exatamente *** como eles estavam no instante X em que o 
SELECT começou a ser executado - mesmo que posteriormente em x+y vc faça o que 
fizer (UPDATE, DELETE, o que quiser!!! :  e comite vc ou não os DMLs !!) , o 
SELECT vai mostrar os dados como estavam em X....
 Exemplificando : imagine que a tua procedure disparou e startou o SELECT 
principal do report na tabela T às 10:00h, e esse SELECT é longo e demora uns 
bons minutos para executar... Aí, ainda com o SELECT sendo executado,  as 
10h01m (digamos) vc fez (via AUTONOMOUS TRANSACTION, que basicamente abre uma 
outra sessão independente da atual) um UPDATE nessa mesma tabela T - comite ou 
não vc esse UPDATE, a query que começou ás 1-h e está rodando ainda **** NÃO 
**** vai enxergar essa alteração, aí se ela faz digamos um COUNT, vc VAI SIM 
ter resultado diferente do real... Sim ??? Perigoso o bastante pra vc ??? Vc 
TEM que se assegurar que o UPDATE não interfere em nenhuma coluna sendo lida 
pela query, justamente sob pena da query em execução NÂO ver essas alterações...
 
  E veja que eu nem estou falando de acesso multi-usuário : veja vc, se vc 
deixar ** É CLARO ** que esse report que faz alterações VAI cedo ou tarde ser 
disparado 2x ao mesmo tempo por dois usuários diferentes da Aplicação, e aí, 
como faz ?? Lost update mais que provável, né não ?? 
  
  ==> São esses tipos de coisa que temos que ter em mente antes de sair 
gambiarrando sem conhecer o mecanismo de transações e consistência de leitura 
do RDBMS Oracle, yep yep ??? 
  
  Pelo que entendi, o que vc quer é que, cfrme os dados vão sendo lidos e 
impressos, faça-se um UPDATE para cada registro lido, certo ?? Normalmente, 
para evitar lost update o que se faz é SERIALIZAR o acesso, com SELECT FOR 
UPDATE ou com LOCK TABLE, e para permitir DMLs na procedure se vc dizer 
exatamente qual tool de report vc está usando quem usa a mesma pode dar a dica 
de como se faz isso na tool.. Praticamente todas as tools de Report realmente 
proíbem DMLs na procedure que alimenta a query mas Permitem triggers PRE/POST 
report e quetais...
  
    []s
    
      Chiappa
  • ... Eduardo Perdomo panc...@gmail.com [oracle_br]
    • ... Alessandro Lúcio Cordeiro da Silva alecordeirosi...@yahoo.com.br [oracle_br]
      • ... Eduardo Perdomo panc...@gmail.com [oracle_br]
        • ... jlchia...@yahoo.com.br [oracle_br]
    • ... Victor Freidinger victor_freidin...@yahoo.com.br [oracle_br]

Responder a