BDE... Argh! Qual a chance de trocar por um SGDB de verdade? Sugestão rápida: Firebird. Aí, vc teria muito mais recursos e eficiência no trato aos dados.
2008/4/30 Sandro <[EMAIL PROTECTED]>: > > Bom dia! > Peguei um sistema ja pronto com o seguinte problema, o programador anterior > implementou os modulos de contas a receber e pagar utilizando uma tela de > entrada onde o usuário escolhe se quer visualizar contas baixadas, em > aberto, por periodo, por valor por cliente todos os tipos de possibilidades > possíveis para o usuário visualizar o lançamento da maneira que ele > desejar. > Mas a questão é que isso foi implemetado utilizando-se de filtro (BD > PARADOX)depois de ecolher o lançameto que ele quer visualizar o mesmo clica > em visualizar e o sistema implementa o filtro necessário àquela pesquisa e > abre o formulario principal. São duas tabelas, uma receber onde constam os > lançamentos e outra Ireceber onde o usuário formaliza a baixa sendo que > esta > ireceber é uma DETAIL da receber. > O que ocorre é que a uns tempos atras o sistema TODO ao abrir, estava > implementado para abrir todas as tabelas deste cerca de 300 tabelas abertas > ao mesmo tempo (em uma rede de 10 maquinas com um servidor dedicado ao BD) > o > que começou a me causar problemas de falta de memória na maioria dos > computadores (Todos minimo celeron 1.1 com 512 rede 10/100 com swith). > Durante este tempo em que todas as tab. eram abertas ao mesmo tempo os > modulos receber e pagar deste sistema por incrivel que pareça funcionavam > muito bem. Quando digo muito bem quero dizer que quando o usuário baixava > um > determinado lançamento esta baixa era quase instantanea. > Mas eu tive que resolver o problema de falata de memoria. E fiz da seguinte > forma simplesmente acabei com as funçoes que abriam todas as tabelas ao > entrar no sistema e agora só abro as mesmas quando necessito (on Demanda) > ou > seja quando estou com o modulo receber aberto só estou com as tabelas > necessárias àquele modulo aberta, quando antes estavam todas as tab. do > sistema abertas. O sistema todo ficou muito mais leve, o problema de falta > de memoria foi resolvido. > Mas para o meu espanto tanto o modulo de receber (só baixa) quanto pagar > (só > baixa) ficaram extremamente lentos cerca de 5m para realizarem uma baixa. > Intervi novamente da seguinte forma verifiquei nas duas tabelas do sistema > receber quais eventos eram estartados desde o momentos em que as tabelas > são > abertas até o momento em que elas são fechadas ( o formulario de receber é > composto por dois grids um para mostrar os dados da tab receberr e outro > para a tab. ireceber.) fiz o seguinte removi todos os eventos (on insert, > on > after insert, onedit, Before post, after post) ao inves de fazer as baixas > direto dentro da grid da tab ireceber, inseri campos edit, dateedit, enfim > todoas os campos da grid ireceber eu inseri campos identicos logo abaixo da > grid e passei a mesma para read only ou seja a baixa que era feita na grid > agora é feita em componetes tEdit e os eventos que eram estartados na tab > ireceber eu inseri em um botão, nomeado de efetuar baixa, que contem todos > os processos de verificação utilizados nos eventos citados acima da tab. > Ireceber. > O sistema melhorou muito quando efetuei a primeira baixa depois de > implemetado isso tudo. Porem esta ocorrendo o seguinte se faço mais que > cinco baixas direto sem fechar o sistema ele volta a ficar lento como > antes. > (Normalmento processamos a cada entrada neste modulos cerca de 20 a 25 > baixas. > Qual seria a solução definitiva e viavel para essa situação. (A lentidão se > da na hora do sistema baixar o lançamento e dar o feedback para o usuario > na > grid ou seja dar o refresh na tab receber e remover aquele registo do > filtro > utilizado na consulta.) -- Timeo hominem unius libri Cogito ergo sum - Carpe diem []s Guionardo Furlan http://guionardo.blogspot.com
