Clipper On Line • Ver Tópico - Browse lento com DBF de mais de 100 mil registros
Página 1 de 2

Browse lento com DBF de mais de 100 mil registros

MensagemEnviado: 21 Out 2019 17:09
por Heero
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:

    
@ 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!

Browse lento com DBF de mais de 100 mil registros

MensagemEnviado: 21 Out 2019 18:10
por MSDN
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.

Browse lento com DBF de mais de 100 mil registros

MensagemEnviado: 21 Out 2019 21:36
por JoséQuintas
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?

Browse lento com DBF de mais de 100 mil registros

MensagemEnviado: 23 Out 2019 10:09
por Heero
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: http://www.pctoledo.com.br/forum/viewtopic.php?f=43&t=15548

Browse lento com DBF de mais de 100 mil registros

MensagemEnviado: 23 Out 2019 10:54
por JoséQuintas
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.

Browse lento com DBF de mais de 100 mil registros

MensagemEnviado: 25 Out 2019 14:21
por Heero
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:

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:

 
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 =/

Browse lento com DBF de mais de 100 mil registros

MensagemEnviado: 25 Out 2019 15:58
por JoséQuintas
À primeira vista nada de errado.
Faça um teste indicando apenas a tag.
INDEX ON chave TAG umnome

Browse lento com DBF de mais de 100 mil registros

MensagemEnviado: 19 Nov 2019 10:34
por NiltonGM
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....

Browse lento com DBF de mais de 100 mil registros

MensagemEnviado: 20 Nov 2019 08:46
por paiva_dbdc
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

Browse lento com DBF de mais de 100 mil registros

MensagemEnviado: 13 Nov 2020 15:46
por marcosLP
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.

Browse lento com DBF de mais de 100 mil registros

MensagemEnviado: 14 Nov 2020 06:45
por alberto_dias
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

Browse lento com DBF de mais de 100 mil registros

MensagemEnviado: 15 Nov 2020 13:23
por JoséQuintas
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.

Browse lento com DBF de mais de 100 mil registros

MensagemEnviado: 15 Nov 2020 21:25
por alberto_dias
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

Browse lento com DBF de mais de 100 mil registros

MensagemEnviado: 16 Nov 2020 07:14
por JoséQuintas
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:
  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.

Browse lento com DBF de mais de 100 mil registros

MensagemEnviado: 16 Nov 2020 07:24
por JoséQuintas
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.

Browse lento com DBF de mais de 100 mil registros

MensagemEnviado: 16 Nov 2020 07:42
por JoséQuintas
Só a última:

Usei DBF/CDX até o final do ano passado.
Troquei pra SQL por ser uma evolução relativamente normal, e gostei muito do resultado.
Com certeza ficou tudo mais rápido e mais prático agora.
NÃO tive nenhum problema com DBF/CDX, mais de 100 mil registros era normal, mas com lentidão conforme o filtro.

Também pode pensar nisso, de usar LetToDbf ou SQL, porque quando é só o servidor que mexe nos arquivos, fica tudo mais rápido e seguro.

Browse lento com DBF de mais de 100 mil registros

MensagemEnviado: 16 Nov 2020 08:10
por Itamar M. Lins Jr.
Olá!
nsar nisso, de usar LetToDbf ou SQL, porque quando é só o servidor que mexe nos arquivos, fica


Uso LetoDbf, com muito mais que isso. Tudo instantâneo. Qualquer pesquisa, uso arquivos temporários "index for ... temporary"
Não cai nada, não perde conexão, não preciso fica verificando se a conexão está ativa, tudo muito rápido.
Alguns com volume superior a 2 mil NFCe por mês. O contas a receber passa de 100 mil registros, registros de itens na NFe de entrada com mais de 90 mil itens tudo instantâneo usando LETODBF.
********************************
Static Function UpGet(oDlg,oTab)
********************************
*
*
PegaVarEntradas()
AtualizaVarEntradas()

tp54e->(ordSetFocus(1))
tp54e->(OrdScope(0,tp50e->es_numero+tp50e->cod_fornec+dtos(tp50e->es_datarec) ))
tp54e->(OrdScope(1,tp50e->es_numero+tp50e->cod_fornec+dtos(tp50e->es_datarec) ))
tp54e->(DbGoTop())
PegaVarItem()
IF oTab:GetActivePage() = 2
   oTab:oBrPd:Refresh()
EndIf


Saudações,
Itamar M. Lins Jr.

Browse lento com DBF de mais de 100 mil registros

MensagemEnviado: 16 Nov 2020 09:11
por alberto_dias
Meus Amigos,
Muito obrigado pelas respostas,
José Quintas,
Itamar,
=========================================================================================================
Que aula, maravilhosa, como a gente aprende muito, com está colaboração de vocês, que possuem um maior conhecimento,
=========================================================================================================
José Quintas,
===========
corri para ver o código do Sistema, que utilizo nos clientes, e achei um monte de índices redundantes.(como você mencionou).
em varias tabelas, nem sei como começar a corrigir.
também sobre evoluir, temos que evoluir, há mito tempo, venho pensando em mudar para SQL, mas vou ser claro,
não sei como começar, por isso volto com outra pergunta,
Você teria um pequeno código, de como acessar uma tabela .dbf, com SQL, incluir um registro, alterar, e excluir,
assim eu poderia testar neste cliente que tenho com mais de 100.000 registros, e ver os efeitos desta mudança,
==========================================================================================================
Itamar,
======
Já tentei o LetoDB, consegui rodar por vários meses, em um cliente,
Gostei de usar, mas tive que parar,
=============================
consegui um ganho de velocidade, verdade, mas tive muitos problemas,
principalmente, quando a quebra de conexão com o Servidor.
e tive uma coisa que eu queria evitar, que era a quebra de índice,
para reindexar, era extremamente rápido,
basicamente, tinha uma configuração do letodb.ini, mas era pouca, faltam informações importantes, documentação, onde checar,
Pergunta,
1) será que usava um LETODB, antigo, você teria um link para eu ver uma versão mais nova, dê repente, uma evolução, poderia voltar a usar,
2) com a minha inexperiência, talvez não soube, como usar corretamente, tem algum exemplo, de como acessar um tabela .dbf, incluir
alterar, e excluir, para eu poder ver onde errei,
3) você mencionou, que não tem como perder conexão, preciso saber como, o LETODB, é muito fácil de implementar em qualquer Sistema,
4) Não sei usar o temporário, em pesquisa, desculpe, você, teria um exemplo, sofro muito com os clientes, justo na hora dos relatórios,
=====================================================================================================================
Se puderem, já agradeço aqui por antecipação,
muito obrigado
Alberto Dias

Browse lento com DBF de mais de 100 mil registros

MensagemEnviado: 16 Nov 2020 10:33
por JoséQuintas
alberto_dias escreveu:corri para ver o código do Sistema, que utilizo nos clientes, e achei um monte de índices redundantes.(como você mencionou).
em varias tabelas, nem sei como começar a corrigir.


Se está usando CDX com tags, dá pra usar o nome da tag ao invés de número.
OrdSetFocus( "nometag" ) ao invés de OrdSetFocus( 3 ), confirme de SET ORDER TO ( "nome" ) funciona.

Qual a diferença?
Selecionando por nome, vai poder apagar os inúteis a qualquer momento, porque não vai importar mais se é 1,2,3.

No final... preocupado com aumentar a quantidade de índices, e talvez vai acabar reduzindo... kkkk

Essa mudança pode ser interessante, mesmo que depois altere pra letodb, vai valer lá também, pode até dar uma confirmada antes de começar a mexer, assim já fica preparado pra mudanças futuras.
Ao mesmo tempo que vai estar melhorando o fonte atual, vai estar mais preparado pra depois.

Browse lento com DBF de mais de 100 mil registros

MensagemEnviado: 16 Nov 2020 16:54
por Itamar M. Lins Jr.
Olá!
) será que usava um LETODB, antigo, você teria um link para eu ver uma versão mais nova, dê repente, uma evolução, poderia voltar a usar,

Novamente, aviso que não uso o LETODB.
Eu uso o LetoDBbF tem esse F no final, do ELCHS.
https://github.com/elchs/LetoDBf

você mencionou, que não tem como perder conexão, preciso saber como, o LETODB, é muito fácil de implementar em qualquer Sistema,


Não perde, 0% de perda de conexão usando o LetoDbf. Todo erro do sistema eu recebo por email. Só recebo erro falta de energia, mudança de IP(estações) ai não tem como evitar.

Não tem segredo, conectou pela primeira vez a conexão ficará ativa até mudar IP(estação/servidor) ou desligar o servidor.

Saudações,
Itamar M. Lins Jr.

Browse lento com DBF de mais de 100 mil registros

MensagemEnviado: 16 Nov 2020 17:14
por Itamar M. Lins Jr.
Olá!
Indexar com arquivos temporários.
cQuery := " dtos(vencimento) >= '"+dtos(inicio)+"' .and. dtos(vencimento) <= '"+dtos(fim)+"' .and. empty(pagamento) "
OrdBy  := "cliente + dtos(vencimento) + cod_venda"

re->(ordSetFocus(1))
tRec := re->(OrdKeyCount())
oBar := HProgressBar():NewBox( "Processando, "+lTrim(str(nRec,9))+" De "+lTrim(str(tRec,9))+" Registro(s)",,,350,,tRec)
Index on &OrdBy Tag re100 for &cQuery temporary additive eval {||oBar:Step(),.T.}
oBar:Close()


Com ou sem LETODBF.

Saudações,
Itamar M. Lins Jr.

Browse lento com DBF de mais de 100 mil registros

MensagemEnviado: 17 Nov 2020 05:33
por alberto_dias
Itamar,
Bom dia,
Desculpe pelo "furo", realmente pensei que o LETODB, fosse o mesmo,
Demorei para responder, pois já corri para programar, para fazer os testes, com o LetoDbf
Baixei os arquivos e estou iniciando os testes do LetoDbf,
Encontrei um problema logo de início, por favor, saberia me dizer se faltou alguma coisa,
============================================================================
Estou tentando compilar o primeiro exemplo, e apesar de ter colocado os arquivos .h e .ch
nos diretórios include, aparece este erro:
==========================================================================================
Nota: eu não sei como colocar o código aqui apresentado, naquela telinha azul bonita, que vocês mostram,
==========================================================================================
17/05/2019 12:52 6.910 test_dbf.prg
17/05/2019 12:52 10.087 test_dbfe.prg
17/05/2019 12:52 6.639 test_file.prg
17/05/2019 12:52 8.925 test_filt.prg
17/05/2019 12:52 12.340 test_mem.prg
16/11/2020 19:37 2.080.259 test_ta.exe
17/05/2019 12:52 5.515 test_ta.prg
17/05/2019 12:52 9.763 test_tr.prg
17/05/2019 12:52 9.840 test_var.prg
36 arquivo(s) 2.277.593 bytes
4 pasta(s) 96.312.471.552 bytes disponíveis

C:\TESTES\LetoDbf\tests>hbmk2 test_dbf
hbmk2: Processando script local: hbmk.hbm
Harbour 3.2.0dev (r2011030937)
Copyright (c) 1999-2020, https://harbour.github.io/
Compiling 'test_dbf.prg'...
Lines 656, Functions/Procedures 1
Generating C source output to 'c:\Temp\hbmk_81pl6w.dir\test_dbf.c'... Done.
c:/hmg.3.5/mingw/bin/../lib/gcc/i686-w64-mingw32/9.3.0/../../../../i686-w64-mingw32/bin/ld.exe: c:/Temp/hbmk_81pl6w.dir/test_dbf.o:test_dbf.c:(.data+0x48): undefined reference to `HB_FUN_LETO_SET'
c:/hmg.3.5/mingw/bin/../lib/gcc/i686-w64-mingw32/9.3.0/../../../../i686-w64-mingw32/bin/ld.exe: c:/Temp/hbmk_81pl6w.dir/test_dbf.o:test_dbf.c:(.data+0x328): undefined reference to `HB_FUN_LETO_DBDRIVER'
collect2.exe: error: ld returned 1 exit status
hbmk2: Erro: Executando linkeditor. 1
gcc.exe c:/Temp/hbmk_81pl6w.dir/test_dbf.o c:/Temp/hbmk_81pl6w.dir/hbmk_lxviiv.o -mwindows -Wl,--start-group -lrddleto -lhbextern -lhbdebug -lhbvmmt -lhbrtl -lhblang -lhbcpage -lgtcgi -lgtpca -lgtstd -lgtwin -lgtwvt -lgtgui -lhbrdd -lhbuddall -lhbusrrdd -lrddntx -lrddcdx -lrddnsx -lrddfpt -lhbrdd -lhbhsx -lhbsix -lhbmacro -lhbcplr -lhbpp -lhbcommon -lhbmainwin -lwinmm -lkernel32 -luser32 -lgdi32 -ladvapi32 -lws2_32 -liphlpapi -lwinspool -lcomctl32 -lcomdlg32 -lshell32 -luuid -lole32 -loleaut32 -lmpr -lmapi32 -limm32 -lmsimg32 -lwininet -lhbpcre -lhbzlib -Wl,--end-group -otest_dbf.exe -Lc:/hmg.3.5/HARBOUR/lib/win/mingw -L../lib

hbmk2: Erro: Referenciado, faltando, mas funç⌡es desconhecida(s): LETO_SET(),
LETO_DBDRIVER()

C:\TESTES\LetoDbf\tests>
====================================================================
Muito obrigado, novamente,
========================
Alberto dias

Browse lento com DBF de mais de 100 mil registros

MensagemEnviado: 17 Nov 2020 13:03
por Itamar M. Lins Jr.
Olá!
Primeiro gerar a LIB do LetoDBf. Fez isso ?
Leu o readme.txt ?

Gerando o servidor .EXE, eu uso o service.
 2.1 building letodb with hbmk2, for all C compilers

Server itself:
    letodb.hbp is ready configured server for Windows and Linux daemon,
    letodbsvc.hbp is ready configured server for use as Windows service.
    -- Windows service  hbmk2 letodbsvc
    -- all other OS     hbmk2 letodb

Gerando a lib, eu uso: hbmk2 rddleto.hbp
Client library:
    -- all OS:          hbmk2 rddleto
    Recommended is to integrate LetoDbf client library into your Harbour environment as an 'addon':
    -- all OS:          hbmk2 rddletoaddon


Depois dessa etapa, linkar com a nossa aplicação.
After successful build as 'addon', you can compile *at any place* your applications with:
    hbmk2 your_application letodb.hbc
else you have to point to the "letodb.hbc", example out of a sub-directory in LetoDBf:
    hbmk2 your_application ../letodb.hbc


Saudações,
Itamar M. Lins Jr.

Browse lento com DBF de mais de 100 mil registros

MensagemEnviado: 18 Nov 2020 07:33
por alberto_dias
Itamar,
Bom dia,
Muito obrigado,
Folga demais de minha parte, querendo tudo na mão !,
Li o Readme.txt
Gerei a lib
Agora compilou,
Mas, deu alguns avisos, chega a compilar, mas quando você tenta, mandar executar, ele não está executando,
============================================================================================
Você pode verificar se estou com mais algum arquivo faltando,
Atenciosamente,
Alberto Dias

Browse lento com DBF de mais de 100 mil registros

MensagemEnviado: 18 Nov 2020 08:10
por Itamar M. Lins Jr.
Olá!
Esse ai não é o SERVIDOR que roda como serviço do windows.
Vc vai precisar colocar ele no iniciar do windows ou executar ele toda vez que ligar o computador.
Então, o erro que está aparecendo é o seguinte: Vc precisa editar o letodb.ini e informar o caminho(path) real o path=c:\minha_base_dbf\ deve existir de fato, senão ele dá erro e não fica como daemon(rodando em segundo plano)
Para ver os erros basta vc editar o arquivo de erro letodbf.log, Por exemplo type letodbf.log ou notepad letobbf.log

O que vc instala ele como serviço do windows é o letodbsvc.hbp que vai gerar o mesmo letodb.exe mas só que vc instala ele definitivo, e toda vez que ligar o computador ele já entra como serviço.

c:\letodbf\bin\letodb.exe install

Parar o letodb na rede:
net stop letodbf_service

remover o serviço(...)
sc delete letodbf_service


Saudações,
Itamar M. Lins Jr.

Browse lento com DBF de mais de 100 mil registros

MensagemEnviado: 18 Nov 2020 08:25
por Itamar M. Lins Jr.
Olá!
Desculpe pelo "furo", realmente pensei que o LETODB, fosse o mesmo,

Esse LetoDbf é muito superior ao LETODB.
Tem várias melhorias, roda em duas threads(tasks), muito mais rápido, sem nenhum bug (grave).
  Port = 2812              -    Server port number, default is 2812 [ then 2813 used for second socket ]
                                    There are two! ports used by server, this and the following number.
                                    ! You ever connect to first port number !

Usa compactação de dados na rede, criptografia, transactions...
  7.2 Transaction functions

A transaction is a series of data changes, which is guaranteed to be applied in a sequence alike
'one block'. In practical life, only record/ file locks are set at server ( no DbAppend() lock ),
and all data changes are buffered at client side. If you DbSeek()/ DbSkip() to a record with changed
data, you will see at client your changes still not applied at server side.
When committing the transaction, one single request about all changes is send to server, which will
start processing data changes firstly after complete receiving the request and further pre-checks.
Up to this point is ensured *all or nothing* of a transaction is processed.
If the server experience hardware problems during processing the sequence, like a power loss, parts
of a transaction will miss ...

As a side effect, transactions are nice for Flock()ed or non-shared, exclusive opened tables, because
for these it leads to a !drastical! improved performance to append 10000 records in a fraction of a second.
For RLock() an insane tremendous overhead is needed, if really **many** records need to be
changed. Example: to Rlock() the 1000th record at server, it must search through 999 existing locks.
In sum a compare have been done 499500 times for the 1000th record.
Only 1000 Rlock() record changes of above example are taken just on the fly, but if there are 10th
of thousands ...


Otimizado para uso com servidor LINUX ou até para quem precisa usar SAMBA(SMB) para compartilhar os DBFs com outros programas usando Linux(SAMBA).

Saudações
Itamar M. Lins Jr.

Browse lento com DBF de mais de 100 mil registros

MensagemEnviado: 18 Nov 2020 15:54
por alberto_dias
Itamar,
Boa tarde,
Sem palavras,
Funcionando,
Deu certo, bora agora testar e fazer os ajustes,
Consegui compilar até o utilitário console, muito útil para acompanhar o uso,
=================================================================
Muito obrigado,
Atenciosamente,
Alberto Dias

Browse lento com DBF de mais de 100 mil registros

MensagemEnviado: 19 Nov 2020 07:37
por Itamar M. Lins Jr.
Olá!
Parabéns, pelo seu desempenho.
Pq muitas vezes encontramos perguntas no forum e vemos claramente que a pessoa, está com muita pressa em resolver o problema dele. E passa batido pelo manual da ferramenta.
Mas sendo aqui um forum de consulta também é bom deixar claro o caminho para as outras pessoas percorrerem.
Então é bom ler o que diz o desenvolvedor que criou a LIB/recurso... Pois simplifica muito as coisas.
A maioria das perguntas do LetoDbf está respondida no readme.txt do Elchs.

Espero que o LetoDBf dê conta do recado ai.

Saudações,
Itamar M. Lins Jr.