dbf muito grande

[José Luiz]

Meu programa em clipper 5.2 está com o dbf muito grande (mais de 10.000 registros) e se tornou muito lenta suas pesquisas. O que posso fazer para solucionar a lentidão do sistema ? (Pentium 4 - 2.4 ghz - 250 mb - windows xp).

[frazato]

tenho dbf com mais de 10 milhões de registros e não tenho lentidão em relação a filtro( não uso o Set filter) uso muito indice temporário.

[Pablo César]

Seja bem vindo ao nosso fórum, José Luiz.

(mais de 10.000 registros) e se tornou muito lenta suas pesquisas.

Sabe que o uso do comando LOCATE, deixam muito lento as pesquisas mesmo. Se for o caso, troque pelo uso do comando SEEK, claro que terá que criar arquivo de índices. Outra forma de armazenamento, caso permitir, pode aramazenar os dados de acordo o MES e ANO. Tudo dependerá da disponibilidade dos dados, do quê trata os seus dados ?.

relação a filtro( não uso o Set filter) uso muito indice temporário

Realmente o uso do SET FILTER, deixam extremamente lentos em todos os casos em que o volume dos dados são grandes. Mas ~deve também estudar a possibilidade de manter os índices criados e não criar a toda hora. Claro que tudo depende da demanda de uso de casos esporádicos.

[Luciano Bonfim]

Caro José Luiz,

quantos campos e qual o tamanho total de cada registro tem no seu DBF "gigante"?

Muito Obrigado

[José Luiz]

Trata-se de um sistema em clipper que desenvolvi em 2002 para o Cartório que trabalho para registro de adolescentes infratores. São 12 dbfs no total. O mais pesquisado é o "bmenor.dbf" com a seguinte estrutura: vmenor - character - 50, vpai - 30, vmae - 30, etc... no total 14 campos mais ou menos nesses tamanhos, com mais de 10.000 registros cada dbf. Uma das pesquisas é pelo nome do menor e está escrita assim:

select 1
if netuse ("bmenor",.f.,3)
index on vmenor to imenor3
seek dmenor
else
close all
endif

if eof()
seek left(dmenor,3)
else
close all
endif

Após, o programa abre o dbedit para pesquisar todas as ocorrências que o menor tiver.

Estou voltando agora a mexer no programa por causa desse problema. Estou por fora das novidades, mas adoro clipper. Desculpa se meu problema é muito simples. Obrigado a todos.

[Luciano Bonfim]

amigo, pelo que entendi do seu c'digo vc está indexando o DBF toda hora que vai fazer um seek.

indexa apenas uma vez e depois basta abrir o NTX dando um set index e pode dar o seek... vai ficar rápido...

[José Luiz]

O problema é que o sistema está em rede com várias pessoas cadastrando e outras pesquisando, então, o índice tem que estar sempre atualizado.

[Maligno]

Uma forma de tornar qualquer pesquisa mais eficiente é trocar o NTX pelo índice composto NSX ou CDX. A biblioteca SIX é uma boa pedida. Até o SET FILTER fica instantâneo.

[Luciano Bonfim]

o índice para estar atualizado basta ser aberto junto com o DBF, näo precisa ficar recriando ele a todo momento...

if adir("*.ntx")=0
use arquivoDBF
index on campo to indice
close data
endif
select 0
use arquivoDBF alias arquivoDBF
set index to indice

quando vc quiser reindexar bata deletar os NTXs da sua pasta do sistemas, ele estando aberto as atualizaçöes feitas pelos usuários säö atualizadas no DBF e nos Indices

[sygecom]

José Luiz, vc pode passar sua app para Clipper 5.3 e usa DBFCDX , onde terá inumeros ganho de desempenho usando a função ORDSCOPE(). Se quiser saber mais procure aqui no forum sobre DBFCDX que tem inumeros post.

[Pablo César]

...está em rede...// o índice tem que estar sempre atualizado

Por isso mesmo que deve ser aberto o DBF junto com o arquivo indice, como ja disse o nosso colega Luciano. Mais do que mudar de NTX para CDX, é você verificar se o arquivo de índice existe, daí é só abrir como por exemplo:

Código: Selecionar todos

USE DBF SHARE
IF FILE("ARQ_INDICE.NTX")
   SET INDEX TO ARQ_INDICE
ELSE
   INDEX ON CAMPO TO ARQ_INDICE
ENDIF

No entanto, também não tiro razão do Maligno e Leonardo sobre o uso de outro RDD, pois o NTX (que é original do Clipper) é menos ágil. Porém de nada vai adiantar, se não usar uma boa lógica na abertura de arquivos. Não pode ser gerado a toda hora o arquivo de índices, isso deve ser evitado. Como disse anteriormente, deve ser utilizado essa prática (de criar arquivos de índices "temporários") só tão somente quando houver uma necessidade MUITO esporádica. E quando for em rede, cri´´a-lo no "C:" ou com um nome temporário, para não haver possibilidade de sobre escrever enquanto outro está usando. Mas repito esta prática é a menos usada, e no seu caso, tomando em conta a quantidade de registros, cada vez irá demorar mais. Então abra o índice que ja tinha sido criado previamente e mais... não deixe de atualizar o arquivo de índice. Istoé, cada vez que fizer ALTERAÇÃO do DBF em questão, abra SEMPRE o arquivo de índice para que seja atualizado. Entendeu ?.

[Maligno]

Acho muito melhor continuar com a versão 5.2 do Clipper e só adicionar a biblioteca SIX que, dizem, tem muitos recursos que a versão 5.3 do Clipper (nunca usei) não tem. Além do quê, as alterações são mínimas.

[José Luiz]

Vou utilizar a sugestão do Pablo por enquanto. Agradeço a todos. Depois aviso de seu certo.

[Pablo César]

Acho muito melhor continuar com a versão 5.2 do Clipper e só adicionar a biblioteca SIX

Por quê SIX e não CDX ? O CDX não funciona em 5.2 ?. Eu ainda não mudei o meu RDD (ainda trabalho com NTX) e estou ainda muito conforme, porém reconheço que o RDD que trabalha com TAG, isto é a idéia de criar apenas um arquivo que sriva para vários ORDERs iria ser mais benéfico, sem contar com outros recursos.

[Maligno]

Já li comentários de que o CDX da versão 5.2 do Clipper é problemático. Pelo sim, pelo não, prefiro a SIX, que além de tudo, oferece vários recursos que o Clipper não tem.

Se você analisar bem, verá que o fato do índice ser composto não é o que há de mais importante, embora seja de grande valor. Na minha opinião, o aspecto mais atraente é o fato do índice ser compactado e ser feito com um algoritmo que torna possível o uso de recursos que com o RDD convencional não é possível.