Perfornance ruim.

[Maurício Elias]

Olá Pessoal...

A base de dados *.DBF no cliente está enorme. A performance do Sistema está caindo.
Uso Clipper5.2 + Blinker 4.0 + *.NTX
Dá prá fazer alguma coisa no Sistema prá melhorar ?

Abraços.

Maurício

[Maligno]

É possível aumentar sensivelmente a velocidade de acesso aos dados indexados se você trocar o velho (e obsoleto) NTX por um RDD mais moderno, como o NSX ou CDX da bilbioteca SIX. Esse assunto, aliás, já foi discutido à exaustão no fórum. Pesquise por "SIX" no mecanismo de busca do fórum. Na dúvida, volte ao assunto. Mas se for possível, continue algum dos vários tópicos que já abordam esse assunto.

Agora, se os dados forem acessados por algum comando de filtragem, nem Mandrake dá jeito. Muito embora, uma eventual reestruturação do código possa diminuir bastante qualquer lentidão, se um eventual filtro for combinado com o índice composto que citei. Uma opinião mais precisa demanda um conhecimento maior da forma como você trabalha.

[rbonotto]

Não sei se é seu caso, mas as rotinas em DBEDIT tendem a ficar lentas com dados muito grandes. Tente trocar o DBEDIT pelo TBROWSE

Abs,

[Maligno]

Em qualquer tipo de browser, em qualquer linguagem, seja DOS ou Windows, navegar por um volume muito grande de dados é uma prática condenada. Em qualquer situação, se navegar pelos dados for algo tão importante que não possa ser dispensado, deve-se limitar a base visualizável. Em SQL é fácil, mas em sistemas de acesso local, como XBase, pode ser necessário limitar a massa de dados com um filtro. Como eu disse antes, um filtro puro não resolve. Sempre ficará tão lento quando maior o volume de dados. Mas uma solução híbrida, com filtro e configuração de escopo por um RDD que permita isso, é uma boa solução. Ou seja, NTX nem a pau.

[alaminojunior]

Não sei se o tal sistema é utilizado em rede por outros computadores, mas se for o caso, pense na viabilidade de aliar à tudo o que já foi aconselhado pelos colegas, acessar o servidor via Terminal Services do Windows.
O servidor precisa ter uma quantidade razoável de memória (acho que uns 512MB pra começar), e estar rodando o Windows XP, ou ainda o 2000 ou 2003 Server. Deste modo toda a tragédia é executada no servidor e você apenas estará visualizando as telas do programa no PC local, diminuindo com isso o tráfego na rede. Detalhe importante: não pode ter nenhuma biblioteca gráfica, pois isto exigiria rodar em tela cheia, coisa que o TS não permite.

[rbonotto]

Eu tive um cliente ha ums 12 anos atras que precisava dividir o dia (07h00 ate as 19h30) de dez em dez minutos, cada uma destas divisões poderia
ser preenchida com os dados de um cliente que ele iria atender, tipo uma agenda com hora inicial de consulta e hora final. A agenda era gerada
quando alguém colocasse um dia que não havia ainda, mas o programa "enxergaria" isto e geraria um ano para frente. Imaginem o tamanho do
banco de dados....
O cara digitou a data de 2014 !!!!! e o sistema gerou todos os dias de 1997 ate 2014, cada dia dividido de 10 em 10 minutos :^|
Nunca imaginei que um dbf suportasse o tamanho, e o sistema quando solicitado uma data qualquer tinha que abrir somente os horarios
daquele dia, de 10 em 10 mintos...ai...filtro seria esperar uma semana...imagine para pc´s de 1997....

O negocio foi: postura erguida, punhos cerrados, olhar no horizonte, respirar fundo e dizer: AGORA F*DEU !

Mas com muitas tentaivas e erros conseguimos, atraves de um tbrowse cabuloso, um desempenho que ate eu desacreditei. Era instantaneo, entrar
na data requisitada e abrir somente os registros requeridos atraves de navegador, e com indices .NTX !!!
O cliente usou este sistema ate o ano passado quando foi contratado por uma universidade americana e fechou o escritorio aqui no Brasil e pediu para eu tirar um back up de seus dados....fiquei absurdado o tamanho que o tal banco de dados havia chegado, mas ainda continuava com entradas instantaneas nas datas requeridas. Codigo, imaginação e help daqui é tudo....

Se alguem quiser as rotinas eu mando por email, é só mandar para ricardobonotto@pop.com.br que mando com prazer.

*ps - desculpem o tanho do post, hoje estou muito feliz pois acabei de fazer meu check de piloto comercial, sonho de minha vida...

Abraços,

[sygecom]

Olá Mauricio,
É muito relativo, o que você chama de performace caindo, depende de como foi programado seu sistema também, tem coisas que ajudam, usando NTX mesmo, ex: revisar todos os COMMIT e mudar para DBCOMMIT() , usar a SUBNTX (da uma procurada no forum que acha sobre SUBNTX).
Outra possibilidade é migrar para CDX do Clipper 5.3 e nos lugar de SET FILTER usar ORDSCOPE(da uma procurada no forum que acha sobre ORDSCOPE).
Veja os ponto que estão mais lentos e post parte dos codigo que vc acha que esta lento e podemos tentar ajudar com talvez outras soluções.

[Maurício Elias]

Olá pessoal.

Não uso DbEdit() nesta rotina em particular. Mas tb isso é outro problema...
Bem, retirei 2 índices do meu arquivo de Pedidos. E tb qq commit do código. Na hora de gerar o nro do pedido, q é chave primária, enroscava no Unlock desta tabela. Me parece q o Unlock faz a função do Commit. Melhorou bastante retirando 2 índices NTX. Assim, fiquei com 6 índices abertos.

Vc acham q usando CDX eu terei uma performance melhorada no geral ?

Abraços.

Maurício

[Maurício Elias]

Outra bucha de canhão.

Neste mesmo cliente, o Sistema não reindexa mais a tabela de EntSai.dbf.
Preciso reindexar manualmente, pelo DBU.
Isso devido ao tamanho da tabela; mesmo motivo da lentidão.
Se eu excluir lançamentos, resolve, mas o cliente não quer.

Como resolver essa reindexação tb ?

Seria CDX ou SDX tb ? Estes são mais estáveis ? O tempo de reindex diminui ?
Usando o Blinker 7 ajudaria ?

Abraços...

Maurício

[Maligno]

CDX ou NSX, ou qualquer índice composto e compactado já traria uma velocidade de indexação muito maior, além de uma maior estabilidade. Usar o BLinker para obter um EXE no modo protegido também faria diferença na questão do gerenciamento de memória.

[alaminojunior]

Na hora de gerar o nro do pedido, q é chave primária, enroscava no Unlock desta tabela. Me parece q o Unlock faz a função do Commit.

Preciso reindexar manualmente, pelo DBU.
Isso devido ao tamanho da tabela; mesmo motivo da lentidão.

Eu tive o mesmo problema em um cliente neste início de ano, ao adaptar o meu pdv e módulo de orçamentos compilados com xHarbour, à retaguarda (em Clipper) de outro programador. O sistema de retaguarda ainda usava indíces NTX e o servidor era Windows98 e um dos terminais WindowsXP. Mesmo fazendo os meus programas trabalharem com NTX e efetuando os devidos set´s, acontecia a mesmíssima coisa.
Solucionei o caso, reestruturando toda a rede e sistemas operacionais das maquinas. Hoje funciona tudo com Windows XP e 2000 Pro. E só pra constar ... há alguns dias terminei o módulo de retaguarda e botei pra funcionar tudo com MySql com Mediator.

[Maligno]

O ideal seria realmente mudar pra SQL num SGBD realmente digno do nome. Mas com CDX/NSX/etc. (índice composto/compacto) já deve ajudar bastante.