Bom dia,
Tenho um formulário com mais de 7 selects com lookup de edição automático pegando valores em outras tabelasque tem de 9 a 70 itens.
Também tenho neste form um mestre/detalhe onde tenho selects na mesma condição.
Quando abro a primeira vez o form carrega rapidinho.
Se clico no insert ou update vou tomar café, jogar wii, ver netflix e depois volto a tempo de ver o formulário exibir a mensagem de post com sucesso.
Hehehehe acho que exagerei, leva uns 30 segundos a 3 minutos.
Sei pelo debug que estes selects demoram porque ao dar o post eles executam todo o lookup de edição novamente após o post.
O que não entendo é porque ao carregar o formulário a primeira vez, antes do post, ele vai rápido ou se faço no bloco de notas (fora do SC) a aplicação criada funciona rápido o post e recarga do Form.
O campo autocomplete acho meio doido os retornos que ele trás.
O que vocês usam neste caso para deixar rápido?
Eu tive que tirar os selects e usar um capture. Mas acho o select mais rápido na hora de escolher o “ítem”.
A próposito verifiquei minhas querys e as geradas com o SC com o comando Explain e não via nada que pudesse gerar atraso no post/recarga.
No shell, comando top, vejo que o mysql não abre o bico, mas o que esta demorando é o apache/php a processar o formulário do SC.
Também limpei o cache do navegador e diretório tmp do SC.
Alguma sugestão?
Obrigado
As vezes intercalo o uso do autocomplete com o lookup, eu tenho um que eu possui 13 campos alguns eu fiz radio (os menores) outros auto-complete e outros select, não tive problemas.
Sabe Robert… Onde sinto mais lentidão é no update do formulário. No insert é sempre mais rápido.
Pelo debug vi que cada select ele faz um select * from tabela.
Eu noto atrás daquela janela ajax de processamento um “update com sucesso” bem rápido
O que demora mesmo é ele recarregar o form após o update e liberar o formulário para uso.
Entendo já rodou a aplicação no modo debug e entrou no update?
Eu acho exagerado o tanto de coisa que faz no sql.
Robert,
Já entrei sim e acho que é uma característica do SC.
Não é a mesma coisa mas já da para perceber com outros posts como este:
http://www.netmake.com.br/forum/index.php/topic,4876.msg20374.html#msg20374
O jeito é usar autocomplete com like limitado, ligações capture ou usar a idéia do Haroldo no post acima.
O Select deve ser manual ou automatico para tabelas pequenas com menos de 20 itens.
Se não… Damos um update e contiuamos a ver o filme no netflix. Hahahahahahahhahaha
hahaha, sim sim… o Haroldo teria uma solução melhor hoje, pena que ele se foi =/
A tabela base do formulário tem muitos campos ?
Olá,
Também senti isto quando utiliza o lookup, onde a tabela a ser “lida” têm muitos registros.
Acredito, …, que este lookup não utiliza o sc_select(), e sim o sc_lookup(), gerando vetor com o resultado, e o uso do sc_lookup() não é recomendado para obtenção de “grandes resultados em registros”. Então, acredito que seja aí o problema, …
Apenas o que entendi quando encontrei este mesmo problema, ainda sou novato na ferramenta, …
Att,
Jocimar
Cleyton,
A aplicação possui 26 campos com 10 chaves estrangeiras.
os selects são nestas 10 chaves estrangeiras.
O SC tem um problema sério de lentidão quando o form é baseado em tabelas com muitos campos, mesmo quando não se usa todos os campos no form. Mas 26 apenas não seria o caso. Já 10 selects talvez seja. Talvez usar auto-complete seria melhor. Neste caso o SC irá buscar os dados na tabela 1 apenas no preenchimento do campo. Geralmente eu uso select apenas em campos que tem resultados bem curtos ou dados manuais.
É a conclusão que eu cheguei.
Fora do SC estes 10 selects não pesam do jeito que montei a estrutura.
Mas no SC Framework pesa demais.
O jeito é o autocomplete ou captura via ligação