PC Toledo

Olá, tenho um arquivo DBF com aproximadamente 120 mil registros. Acontece que quando abro em um terminal, mesmo com o sistema no servidor, abre perfeitamente e com boa performance. Agora se abro em outro computador ao mesmo tempo, os dois terminais ficam extremamente lentos com esse DBF aberto. Alguma dica ? :/

MiniGui Extended, Harbour 3.2, BCC55

Código do meu Browse:

Código: Selecionar todos

    
@ 100,1 browse Produtos;
        parent janela;
        width janela.Width  - 20;
        height janela.Height - 175 ;  
        headers {'Cód. Produto','Descrição','Aplicação','Número da Peça','Código Original','UN'} ;
        widths {85,235,225,150,225,35} ;
        workarea prd ;
        fields {'Edprd(cdprod)','descri','aplic','numpeca','numorg','unimed'} ;
        justify {1,0,0,1,0,2};
        on dblclick Aplicacao:Alterar() ;
        on change nil;
        on gotfocus nil

Obrigado!

A melhor solução para o seu caso, é não usar o Browse para "carregar" mais de 100 mil registros, e sim ter o campo PESQUISA e de acordo com o seu conteúdo mostrar as informações.

Estranho isso.
Um terminal ok, dois terminais fica lento.
normal terminal ficar mais lento que servidor, mas entre os terminais, deveria ser velocidade equivalente.
Também pode ser normal se estiver usando o servidor, e não ter os devidos cuidados no programa.

Aquilo de tempo pra Windows faz diferença, mas deveria ser problema em browse DOS, e não em browse GUI.

Tive um problema desse tipo na época do Clipper, nos tempos do Windows 98.
Nessa época passei a usar OSLIB e SIXCDX, e tudo ficou rápido, não sei se foi coincidência, ou se tem alguma coisa a ver.

Também é conhecido que nos índices há bloqueio pra leitura, em páginas do índice, mas não pra chegar nesse ponto.
A não ser que o browse usado com edição faça bloqueios automáticos e estejam atrapalhando.

Tem programa de banco no servidor? isso sim faz muuuuita diferença?

MSDN escreveu:A melhor solução para o seu caso, é não usar o Browse para "carregar" mais de 100 mil registros, e sim ter o campo PESQUISA e de acordo com o seu conteúdo mostrar as informações.

MSDN, Obrigado pela dica! =)

JoséQuintas escreveu:Estranho isso.
Um terminal ok, dois terminais fica lento.
normal terminal ficar mais lento que servidor, mas entre os terminais, deveria ser velocidade equivalente.
Também pode ser normal se estiver usando o servidor, e não ter os devidos cuidados no programa.

Aquilo de tempo pra Windows faz diferença, mas deveria ser problema em browse DOS, e não em browse GUI.

Tive um problema desse tipo na época do Clipper, nos tempos do Windows 98.
Nessa época passei a usar OSLIB e SIXCDX, e tudo ficou rápido, não sei se foi coincidência, ou se tem alguma coisa a ver.

Também é conhecido que nos índices há bloqueio pra leitura, em páginas do índice, mas não pra chegar nesse ponto.
A não ser que o browse usado com edição faça bloqueios automáticos e estejam atrapalhando.

Tem programa de banco no servidor? isso sim faz muuuuita diferença?

JoséQuintas, não tem, é apenas a aplicação e antivírus Kaspersky instalado. Aqui são dois servidores com Windows Server 2012 R2 e Ubuntu Server 18.04 LTS com samba. Foi testado nos dois e o resultado foi o mesmo.

Porém você me deu uma luz quanto aos índices. Decidi testar com .CDX e o ganho de perfomance foi muito grande. É um sistema que que atualmente roda no modo console e os dados são mostrados para o usuário através do DBEdit. Na conversão com MiniGui estamos usando Browse para DBF e Grid para Arrays. Não sei se o Browse tem algum problema com índices NTX :/

Com índice .CDX abri em cinco terminais e não tive perda de performance. O CDX é rápido assim mesmo ? Isso deu até uma animada rs, porém vamos precisar rever algumas coisas pois de acordo com outro tópico seu, algumas coisas mudam na hora de indexar. Inclusive usamos o SET RELATION que aparentemente deixou de funcionar, vamos ter que ver isso também.

Tópico referenciado: https://pctoledo.org/forum/viewto ... 43&t=15548

Heero escreveu:Com índice .CDX abri em cinco terminais e não tive perda de performance.
O CDX é rápido assim mesmo ?
Isso deu até uma animada rs, porém vamos precisar rever algumas coisas pois de acordo com outro tópico seu, algumas coisas mudam na hora de indexar. Inclusive usamos o SET RELATION que aparentemente deixou de funcionar, vamos ter que ver isso também.Tópico referenciado: viewtopic.php?f=43&t=15548

Por coincidência o post é de 21/10, mas de 2014, exatamente 5 anos atrás.
Não deveria fazer diferença pra set relation, a não ser que não tenha definido o índice que precisa ser o default dessa situação.

Foi um chute meu...
Daquele tipo: se aqui funciona e aí não, qual poderia ser a diferença.
Por isso mencionei o CDX.

Pensei agora no seguinte:

Se CDX deixou tudo mais rápido na rede.....
Será que problemas em rede, que muitos mencionam, não podem estar relacionados a usarem NTX?

Quem não mudou pra CDX ainda, agora tem um bom motivo pra mudar.

JoséQuintas escreveu:Não deveria fazer diferença pra set relation, a não ser que não tenha definido o índice que precisa ser o default dessa situação.

Realmente ficou muito rápido.

Porém não sei se devo abrir outro tópico pra falar a respeito de CDX, mas praticamente todas as indexações concatenadas deixaram de funcionar. Somente as que possuem apenas uma variável continuam funcionando.

Em NTX era assim:

Código: Selecionar todos

if !AbreArq(dv,'produto','prd',' ') -> Minha rotina pra abrir DBFs
      return
endif

 index on strzero(cdprod,8,0) to &dv\produto1
 index on descri to &dv\produto2
 index on numpeca  to &dv\produto3
 index on subs(strzero(cdprod,8,0),1,3)+numpeca to &dv\produto4 
 index on strzero(cdbarra,13,0) to &dv\produto5
 index on codaux to &dv\produto6
 index on numorg to &dv\produto7

...
set order to 1
set order to 2

seek tal

etc.

Em CDX ficou assim:

Código: Selecionar todos

 
index on strzero(cdprod,8,0) TAG produto1 to &dv\produto
index on descri TAG produto2 to &dv\produto
index on numpeca TAG produto3 to &dv\produto
index on subs(strzero(cdprod,8,0),1,3)+numpeca TAG produto4 to &dv\produto
index on strzero(cdbarra,13,0)  TAG produto5 to &dv\produto
index on codaux TAG produto6 to &dv\produto
index on numorg TAG produto7 to &dv\produto

Em CDX tentei:

OrdSetFocus('produto1') e OrdSetFocus(1)
OrdSetFocus('produto2') e OrdSetFocus(2)

Porém em especial somente as indexações com concatenações não mais funcionando, o exemplo acima é só um dos casos.

Estou fazendo algo de errado ? Qualquer dica ou crítica é bem vinda =/

À primeira vista nada de errado.
Faça um teste indicando apenas a tag.
INDEX ON chave TAG umnome

Enviado: **19 Nov 2019 10:34**

Vcs ainda usam DBF/CDX?? Não acredito!
Aposto a tela ainda é tipo clipper DOS... mude para SQL e esqueça esses problemas, vc terá novos problemas mas esses nunca mais....

Enviado: **20 Nov 2019 08:46**

bom dia

e se vc usa xhb use RMDBFCDX que ainda ganga de 20 a 30%

*//-- solicitacao do RDD DBFCDX

*request DBFCDX
REQUEST RMDBFCDX // Utilize essa linha para utilizar a rotina para filtros rapidos

request DTOS
request DELETED
request DESCEND

*RddSetDefault( "DBFCDX" )
RddSetDefault("RMDBFCDX") // Utilize esse linha para definir CDX como padrao usando fitros otimizados

REQUEST OrdKeyCount, OrdKeyNo // DbfCdx

Enviado: **13 Nov 2020 15:46**

100 mil registros...caramba!
Cada um tem sua preferência eu não uso browse mais, a não ser é lógico para menos de 100 registro por ex: uma tabela de sexo, estado civel, essas coisas, no restante uso um campo de pesquisa e ai preenche a GRID com as informações que preciso. É rápido e ainda desafoga o processador.

Enviado: **14 Nov 2020 06:45**

Bom dia a todos,
Gostaria de fazer um pergunta ao paiva_dbdc,
Se você, puder me ajudar, agradeço por antecipação,
meu conhecimento em BD e nestes comandos de RDD é zero ou nula para ser mais exato,
e aqui neste forum tenho conseguido muita informação importante, que tem feito melhorar o Sistema que Utilizo nos nossos clientes,
Por favor paiva_dbdc tenha paciência, vou tenta demonstrar o meu problema que ocorre de vez em quando, o melhor possível, agradeço,
------------------------------------------
Vi a sua resposta, sobre esse tema,
Possui clientes com 5.000 registros
e clientes com mais de 100.00O registros, rodando em rede com mais de 14 máquinas,
* -----------------------------------------------------------------------------------------------------
Utilizo o Harbor,
Harbour 3.2.0dev (r1703241902)
Copyright (c) 1999-2016, http://harbour-project.org/
* -------------------------------------------------------------
e uso a seguinte configuração no Sistema Principal, começamos em 1991 com o Clipper Summer87, e fomos até o Clipper 5.3 e Passamos ao Harbour:
* ------------------------------------------
* 17/05/2007 AS 20:30 HS - DBFLOC
#DEFINE DBFLOCK_CL53 2
REQUEST DBFCDX
REQUEST HB_LANG_PT
REQUEST HB_CODEPAGE_PT850
*
FUNCTION MAIN() // PARA O HARBOUR/XHARBOUR WINDOWS 32 BITS FUNC MAIN E OBRIGATORIA
PARAMETERS tipo
*
RDDSETDEFAULT("DBFCDX")
* 17/05/2007 AS 20:30 HS
SET DBFLOCKSCHEME TO DBFLOCK_CL53
HB_LANGSELECT("PT")
HB_SETCODEPAGE("PT850")
SETMODE(26,80)
* ---------------------------------------------------------------------------------------------------------------------
quando usados sem filtros, funciona perfeitamente, inclusive em 100.000 Registros ou " Mais "
* ---------------------------------------------------------------------------------------------------------------------
quando Utilizo os filtros, Set filter,
O que acontece,
mesmo em clientes que não tem tudo isso uns 5.000 Registros, com umas 4 máquinas apenas em rede (pouco),
e quando uns 25 % + ou - nos registros possuem dois tipos de informação exemplo: ( ATIVO / INATIVO )
e tenho que usar o filtro, para apresentar na tela do cliente o que esta ATIVO OU INATIVO ai ferra,
é visível a lentidão da pesquisa o DBEDIT(), chega a desfolhar na tela o cliente, demora segundos preciosos na pesquisa,
* --------------------------------------------------------------------------------------------------------------------------------------------
As perguntas são:
1) Posso trocar também esta configuração para o Harbour ?
2) Tem algum outro efeito ( colateral ) ?
3) Se poder trocar, ao utilizar o filtro deve melhorar a pesquisa, nesta porcentagem 30 % ? ( se foi isso que eu entendi )
* -------------------------------------------------------------------------
Novamente agradeço se puder responder,
* ----------------------------------------------
Alberto Dias

Enviado: **15 Nov 2020 13:23**

alberto_dias escreveu:e quando uns 25 % + ou - nos registros possuem dois tipos de informação exemplo: ( ATIVO / INATIVO )
e tenho que usar o filtro, para apresentar na tela do cliente o que esta ATIVO OU INATIVO ai ferra,

Se usar muito, crie um índice só por ativo/inativo, e índice filtrado.

INDEX ON ... TO .... FOR ....

CDX vai ser melhor, e o limite de CDX é 50 índices por arquivo CDX, então dá pra otimizar muita coisa.

Enviado: **15 Nov 2020 21:25**

Boa noite,
Obrigado,
José Quintas,
Agradeço a ajuda,
===============================================================================
Tá aí, uma coisa que eu não sabia, 50 no CDX, tinham me dito para não passar de 6,
Realmente, se puder 50, dá para fazer muita coisa, e resolveria o meu problema dos inativos,
========================================================================================================
Aproveitando o seu conhecimento em Banco de Dados, não fique chateado se eu fizer mais umas perguntas,
1) aumentando os CDX, têm algum efeito colateral, ?
Exemplo: demora mais a indexação, é mais suscetível de quebra do índice, quando o programa está rodando em rede, ?
2) Outra pergunta se não for abusar, qual o tamanho do .dbf para ele ficar instável,
em tamanho kb ou na quantidade de registros, ?
3) Quantos registros um Banco de Dados em .dbf com .Cdx suporta, ?
========================================================================================================
Novamente, muito obrigado
Atenciosamente,
Alberto Dias

Enviado: **16 Nov 2020 07:14**

alberto_dias escreveu:Tá aí, uma coisa que eu não sabia, 50 no CDX, tinham me dito para não passar de 6,
Realmente, se puder 50, dá para fazer muita coisa, e resolveria o meu problema dos inativos,
========================================================================================================
Aproveitando o seu conhecimento em Banco de Dados, não fique chateado se eu fizer mais umas perguntas,
1) aumentando os CDX, têm algum efeito colateral, ?
Exemplo: demora mais a indexação, é mais suscetível de quebra do índice, quando o programa está rodando em rede, ?
2) Outra pergunta se não for abusar, qual o tamanho do .dbf para ele ficar instável,
em tamanho kb ou na quantidade de registros, ?
3) Quantos registros um Banco de Dados em .dbf com .Cdx suporta, ?

O limite é do sistema operacional/arquitetura: arquivos com até 4GB em 32 bits, ou 4TB em 64 bits
O que sempre usei foi bloquear o mínimo possível: bloqueia/salva/libera, sem aquilo de deixar bloqueado por tempo indeterminado.

sobre CDX encontrei isto, limite pra CLIPPER, até 50 é considerado normal:

Código: Selecionar todos

  You can have several compound indexes for a single database file, giving
  you the ability to go well beyond Clipper's normal 15 index limit.  A
  compound .CDX index can have as many as 99 tags, but the practical limit
  is around 50.

http://www.x-hacker.org/ng/six3/ng87f03.html

Usei muito isso do INDEX FOR, principalmente pra produtos, pra mostrar somente o que está liberado pra venda.
E nos pedidos, numa época usei um temporário: INDEX FOR WHILE, pra indexar somente produtos de um único pedido, mas depois mudei pra SET SCOPE e eliminei o temporário.
Aliás... um índice pelo ativo/inativo junto com SET SCOPE também pode ser interessante.

Enviado: **16 Nov 2020 07:24**

alberto_dias escreveu:1) aumentando os CDX, têm algum efeito colateral, ?
Exemplo: demora mais a indexação, é mais suscetível de quebra do índice, quando o programa está rodando em rede, ?
2) Outra pergunta se não for abusar, qual o tamanho do .dbf para ele ficar instável,
em tamanho kb ou na quantidade de registros, ?

É lógico que quanto mais índices, mais demora pra indexar, e são mais arquivos pra atualizar.
Mas dos tempos do Clipper pra agora, tudo ficou muito mais rápido também.
É só não abusar, e não criar índice redundante.

Por exemplo:

Index on cliente
index on cliente + pedido

O primeiro índice é dispensável, porque o segundo atende os dois casos.

PC Toledo

Browse lento com DBF de mais de 100 mil registros

Browse lento com DBF de mais de 100 mil registros

Browse lento com DBF de mais de 100 mil registros

Browse lento com DBF de mais de 100 mil registros

Browse lento com DBF de mais de 100 mil registros

Browse lento com DBF de mais de 100 mil registros

Browse lento com DBF de mais de 100 mil registros

Browse lento com DBF de mais de 100 mil registros

Browse lento com DBF de mais de 100 mil registros

Browse lento com DBF de mais de 100 mil registros

Browse lento com DBF de mais de 100 mil registros

Browse lento com DBF de mais de 100 mil registros

Browse lento com DBF de mais de 100 mil registros

Browse lento com DBF de mais de 100 mil registros

Browse lento com DBF de mais de 100 mil registros

Browse lento com DBF de mais de 100 mil registros