LOV demorada. O que fazer?
- dr_gori
- Moderador
- Mensagens: 5013
- Registrado em: Seg, 03 Mai 2004 3:08 pm
- Localização: Portland, OR USA
- Contato:
Thomas F. G
Você já respondeu a dúvida de alguém hoje?
https://glufke.net/oracle/search.php?search_id=unanswered
Você já respondeu a dúvida de alguém hoje?
https://glufke.net/oracle/search.php?search_id=unanswered
***ERRADO***
Eis a resposta:
A LOV POPULA o record-group cada vez que é executada e guarda na memória o Record-Group! Se a LOV possui 3.000 registros, os 3.000 serão enviados do Servidor para o record-group do cliente!!! É por isso que sua LOV demora nesse caso! Todas milhares de linhas passam do servidor até você pela VPN. (que é lenta, comparada a uma rede de 100 Mbits)
Vejam o Trace de uma LOV Grande: (essa abaixo é de Funcionários)
**** fez 580 fetch pois eu diminuí a quantidade de FETCH pra 10 em 10... Totalizando quase 6.000 registros!!! Veja que a LOV não funciona como um BLOCO, que vai fazendo os fetch a medida que é necessário. A LOV busca TUDO de uma vez só, não importando se o usuário filtrou ou não.
Eis a DICA:
Existe uma propriedade da LOV chamada Automatic-Refresh. O default é YES, fazendo com que CADA VEZ que a LOV é acionada, ela busca os dados atuais. Se alterada para NO, ela vai buscar os dados da LOV APENAS uma vez, na segunda vez que é chamada, ela usará o Record-Group populado anteriormente. Por incrível que pareça, a LOV de funcionários demorou ZERO segundos pra aparecer!!! (a primeira vez demorou o tempo normal)
Talvez essa seja uma boa solução para as LOVS mais demoradas! É claro, que se alguém incluir um funcionário nesse meio tempo, ele não vai aparecer. Se for necessário popular em Tempo de Execução, pode ser populada com POPULATE_GROUP. OU o usuário apenas SAI do formulário e entra de novo...
É claro que essa solução é meio drástica... Deve ser muito bem pensada antes de ser aplicada pra valer. Tem que avaliar se a informação da LOV muda constantemente, ou não... Se isso não vai gerar algum problema, etc.
Eis a resposta:
A LOV POPULA o record-group cada vez que é executada e guarda na memória o Record-Group! Se a LOV possui 3.000 registros, os 3.000 serão enviados do Servidor para o record-group do cliente!!! É por isso que sua LOV demora nesse caso! Todas milhares de linhas passam do servidor até você pela VPN. (que é lenta, comparada a uma rede de 100 Mbits)
Vejam o Trace de uma LOV Grande: (essa abaixo é de Funcionários)
********************************************************************************
SELECT COD_FUNC, NOME_FUNC
FROM FUNCIONARIOS
call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 580 0.00 0.00 0 18584 0 5790
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 582 0.00 0.00 0 18584 0 5790
Misses in library cache during parse: 1
Optimizer goal: CHOOSE
Parsing user id: 121
********************************************************************************
Eis a DICA:
Existe uma propriedade da LOV chamada Automatic-Refresh. O default é YES, fazendo com que CADA VEZ que a LOV é acionada, ela busca os dados atuais. Se alterada para NO, ela vai buscar os dados da LOV APENAS uma vez, na segunda vez que é chamada, ela usará o Record-Group populado anteriormente. Por incrível que pareça, a LOV de funcionários demorou ZERO segundos pra aparecer!!! (a primeira vez demorou o tempo normal)
Talvez essa seja uma boa solução para as LOVS mais demoradas! É claro, que se alguém incluir um funcionário nesse meio tempo, ele não vai aparecer. Se for necessário popular em Tempo de Execução, pode ser populada com POPULATE_GROUP. OU o usuário apenas SAI do formulário e entra de novo...
É claro que essa solução é meio drástica... Deve ser muito bem pensada antes de ser aplicada pra valer. Tem que avaliar se a informação da LOV muda constantemente, ou não... Se isso não vai gerar algum problema, etc.
-
- Informação
-
Quem está online
Usuários navegando neste fórum: Nenhum usuário registrado e 2 visitantes