Harbour e Delphi DBF/CDX com BDE

por **leandromilersantana** » 02 Set 2019 18:05

Caros amigos, boa tarde !!!

Sou programador clipper a muitos anos, quando surgiu a necessidade CTe Eletronico, XML, SEFAZ, etc. Tornei meu sistema hybrido usando DELPHI e BDE.

Recentemente migruei meu codigo pra harbour 3.4 usando tela padrão texto, e hoje ainda mantenho o mesmo software harbour e clipper com modulos Delphi.

Pois bem, o Harbour está funcionando muito bem e muito rápido. Percebo que ele é extremamente rápido em máquinas rapidas e maquinas mais antigas ele é bem mais lento que o clipper.

Configura o BDE criando um Alias como foxPro e coloco no INIT como shared. No clipper funciona perfeitamente, e consigo usar meu programa clipper e delphi simultâneo com vários usuários abertos. Detalhe, uso 2003 server 32 bits e os usuarios acessam tudo via TS.

Nesta migração que faz 2 meses, alguns clientes ja estão usando o harbour, mas, percebo que sempre o último registro digitado, fica bloqueado, o Delphi não consegue editar. Os outros registros já digitados o Delphi com BDE grava perfeitamente igual no clipper.

Procurei várias soluções e ainda não encontrei devido se iniciante no Harbour.

Ja experimentei usar dbunlockall() sempre após digitar os registros, mas mesmo assim o último registro sempre fica bloqueado, tenho que fechar o programa em Harbour pra conseguir gerar e editar o registro no Delphi

Algum amigo iluminado aqui, poderia por favor me dar essa grandiosa ajuda. O que devo fazer pra solucionar este problema. Tenho que por enquanto continuar usando dbf/cdx.

Podem me ajudar?

Desde já agradeço o apoio da comunidade.

Grande abraço.

por **Itamar M. Lins Jr.** » 02 Set 2019 18:27

Ola!
O Harbour é mais rápido até em maquinas velhas. Não use nas maquinas velhas GTWIN use WVT, WVG.
Vc não colocou como está fazendo.
Vc deve usar a opção de travamento compatível com clipper.

cRddName pode ser RDDNTX ou RDDCDX ou RDDSIX.

   ? dbInfo( DBI_LOCKSCHEME ) 
   rddInfo( RDDI_LOCKSCHEME, DB_DBFLOCK_*, cRddName )

SET DBFLOCKSCHEME TO
Constant Value Description
DB_DBFLOCK_DEFAULT 0 Default locking scheme
DB_DBFLOCK_CLIP 1 Clipper 5.2 locking scheme
DB_DBFLOCK_CL53 2 Clipper 5.3 locking scheme
DB_DBFLOCK_VFP 3 Visual FoxPro locking scheme
DB_DBFLOCK_CL53EXT 4 Emulated shared locking
DB_DBFLOCK_XHB64 5 Locking scheme for files > 4GB

Saudações,
Itamar M. Lins Jr.

por **JoséQuintas** » 02 Set 2019 20:53

leandromilersantana escreveu:a experimentei usar dbunlockall() sempre após digitar os registros, mas mesmo assim o último registro sempre fica bloqueado, tenho que fechar o programa em Harbour pra conseguir gerar e editar o registro no Delphi

SKIP 0
UNLOCK

Se mesmo assim tem dúvida, ou até pra economizar fonte, ou pra sempre usar na ordem certa....
E o mesmo usando RecAppend(), RecDelete()
E principalmente esqueça dbCommit() e similares, essas invenções dos infernos.
E, não custa avisar, a mesma coisa depois de terminar o APPEND/REPLACE.

FUNCTION RecUnlock()
   SKIP 0
   UNLOCK
   RETURN NIL

Passe a usar RecUnlock() e depois decida o que fazer.

Outra coisa:
Dê tempo ao Windows

DO WHILE ! RLock()
   Inkey(0.3)
ENDDO

Outra coisa que pode simplificar configuração/compatibilidade:

REQUEST SIXCDX
RddSetDefault( "SIXCDX" )

leandromilersantana escreveu: Percebo que ele é extremamente rápido em máquinas rapidas e maquinas mais antigas ele é bem mais lento que o clipper.

Talvez o que já mencionei acima sobre dar tempo ao Windows.
Em máquina lenta, isso faz mais diferença ainda.
Isto com Inkey() pode ficar extremamente mais rápido do que sem Inkey()

DO WHILE ! Eof()
   Inkey()
   SKIP
ENDDO

Verifique direito. Harbour mais lento que Clipper impossível...
Tem uns programinhas de bost... que usuários Clipper instalam na máquina, pra não migrar pra algo mais moderno, que fod.em com toda máquina, porque mexe em configurações internas do Windows, que não voltam mais. Além de não resolverem o problema ainda complicam a máquina do cliente.

Veja no gerenciador de arquivos, qual o programa que está tomando mais processamento.

Veja a bost. do warsaw que é outra invenção dos infernos, desinstale se existir, e mostre a diferença para o cliente, se ele insistir com isso problema dele.

Assine o programa, antivírus é problema com programa não assinado.

De que tipo de máquina velha estamos falando? máquina de um core só? Celeron velho? Máquina com cooler que precisaria ser trocado mas não é? máquina que obrigatoriamente precisaria de cooler mas não colocaram? máquina com 256MB de memória e Windows XP? Arquivos de 3GB em máquina velha? Rede 10MB ao invés de 100MB? Rede bichada?
Quantos usuários? 1.000, 100, 10 ?

2003 Server 32 bits... deveria ser 64 bits, mas mesmo assim, máquina com 2003 Server não costuma ser antiga.

Estou relativamente perto, em SP, Harbour mais lento que Clipper, só acredito vendo.
Só vi isso há uns 10 anos atrás, no tempo do XHarbour, onde telas eram mais lentas.
Ou no Harbour, no tempo do Windows 98, por não configurar UNICOWS.

por **JoséQuintas** » 02 Set 2019 21:12

Ainda no assunto

DO WHILE ! RLock()
ENDDO

Teste de registro bloqueado sem intervalo de tempo.... no Clipper digamos que seriam 100 checagens por segundo, e no Harbour seriam 10.000 checagens por segundo... isso ocupando tempo do Windows, tempo de rede, etc. etc. etc. e se forem vários usuários então... fud.eu.
Já colocando um tempo, um Inkey() no caso do Harbour, ou OL_Yeld() no caso do Clipper, e um pequeno intervalo de tempo, a rede e o Windows conseguem "respirar", adiantando tarefas pendentes, e talvez até ajudando que a liberação seja mais rápida - de repente o terminal quer liberar e os outros usuários não deixam por causa de tanta tentativa de bloqueio.
Se se juntar isso ao warsaw dos infernos então....que se infiltra em toda comunicação de rede... e todo uso de tela...

Outra coisa comum:

DO WHILE ! Eof()
   ? RecNo()
   SKIP
ENDDO

Quanto mais coisa mostrar pior, atualização de tela é demorada, mas isso influenciaria apenas rotinas de atualização ou algo do tipo.
HARBOUR pode ser console mas NÃO É DOS/16bits.
O Windows dá um tratamento diferente ao DOS/16 bits, deixando mais lento pra não atrapalhar.
No Harbour, como é 32bits, fica por conta dele e/ou do programador.

por **leandromilersantana** » 03 Set 2019 14:29

Ok Pessoal, muito obrigado pelas dicas, vou tentar fazer o SET DBFLOCKSCHEME TO DB_DBFLOCK_VFP e tambem utilizar o skip 0 + unlock, vamos ver se vai corrigir o problema.
Agora outra coisa não entendi direito a respeito do inkey() em que lugar coloco o inkey() pra deixar o sistema mais rapido ? outra coisa que percebi tbem, as vezes as dbedits ficam mais lentas um pouco.

por **JoséQuintas** » 03 Set 2019 16:15

leandromilersantana escreveu:gora outra coisa não entendi direito a respeito do inkey() em que lugar coloco o inkey() pra deixar o sistema mais rapido ? outra coisa que percebi tbem, as vezes as dbedits ficam mais lentas um pouco.

Já deve ter usado no Delphi algo do estilo do DoEvents() ou algo assim, pra janela não travar ou algo do tipo.
O Inkey() seria algo equivalente, mas é lógico que se exagerar pode ficar até mais lento que o normal.

DbEdits lentos...
com SET FILTER é normal, porque está "passeando" por todo arquivo, não apenas pelo que vê na tela.
Mas sem filtro... melhor revisar, concorrência de bloqueio talvez.

Se tudo vém do servidor...
A lentidão é quando usa em conjunto, ou mesmo o aplicativo sem Delphi acessando?

É questão de tentar identificar aonde fica mais lento, assim dá pra ter uma idéia de onde pode estar o "causador" da lentidão.

por **JoséQuintas** » 03 Set 2019 16:20

Tem também o ADS - Advantage Database Server.
O ODBC pode ser usado sem servidor, pode ser mais compatível, é questão de testar.
Era o que eu usava no Visual Basic.

O único detalhe é que ele segura todos os arquivos da pasta, não permitindo uso exclusivo, somente compartilhado.

por **leandromilersantana** » 03 Set 2019 16:28

Sim, a lentidão geralmente vem quando uso o set filter.

Outro dia vi um post aqui de um fonte dbedit.prg que tem o dbedit feito em tbrowse, e basta compilar junto no sistema em harbour, que todos os dbedits ele usaria essa nova versão.

È isso mesmo ?

Relmente vai melhorar a performance nos meus dbedits ?

por **JoséQuintas** » 03 Set 2019 16:34

leandromilersantana escreveu:Relmente vai melhorar a performance nos meus dbedits ?

Não existe mágica.
Depende do porquê de seus dbedits estarem lentos.

Digamos que você tem itens de pedido, e faz um filtro de um número de pedido, e chama dbedit()... ou tbrowse()....
isso fica muito lento, quanto mais registros no arquivo pior.

Mas... existe o SET SCOPE que poderia fazer a mesma coisa, e a diferença é ... tanto faz o tamanho do arquivo, vai ser sempre rápido.

Cada situação/problema pode ter uma solução diferente.

por **leandromilersantana** » 03 Set 2019 17:19

Maravilha !!! Vou também dar uma olhada no set scope.

Agradeço muito atenção do amigos programadores.

Grande abraço a todos !!!! :xau

Quem está online