Olá Rocinha,
TEMPORARY ADDITIVE faz parte do Harbour 3.2 e 3.4

Moderador: Moderadores
harbour 3.2 dev(r1510132105)
minigui extend 2.5.4.2015.10.21
DBF CDX
Faz o seguinte, melhora o filtro, testa e posta aqui pra dizer se deu certo.
é rede mapeada ? etc...
Deve ser DBF,,,,
- Criar Ãndices pra agilizar
- usar hbnetio e processar relatório no servidor
- processar relatório no servidor
- deixar relatórios prontos a noite
- etc.
Isso é problema de rede. E se for WIFI piora.
Dica: Se placas de rede, roteadores e hubs forem de mesma marca melhor ainda.
Tenta ver se a configuração da placa de rede tá Full ou half duplex, ou seja uma rede que é 100 MB é placa tá trabalhando como 10 Mbps
vc usa dbf temporarias? para gerar esse relatório??
ou é direto da dbf?
Quando vi que doideira seria trocar meus Set Filters sofisticados quase parei. Mas como já vinha usando o OrdScope() a contendo em meus aplicativos DOS pensei:
EU ao pesquisar produtos la na venda faço:
o nome do produto ou Partes do nome separados por (:) === .or. ou por (;) === .and.
Acesso pela rede SEMPRE é mais lento do que local.
USEM O SQL COMO BASE.
tempofat->(dbgotop())
do while ! tempofat->(eof())
*--------------calculo o valor do documento
*------------------------------------------
vvlCusto:=fcustoDocum(vdocum,vnfci) // a demora no terminal esta aqui
*---------------------------------
tempofat->(dbskip())
enddo
FUNC fcustoDocum(Xdocum,xnfci)
// calcula o custo total do documento, produto por produto
local xarq, xcustoProd:=0,xcustoDoc:=0 , xabre:=.f. , mx:={}
if ! xnfci $ "NF-CI"
MSGSTOP("erro na funcao fcustodocum, consulte a assitencia")
retu xcustodoc // retorno 0 mesmo
endif
if xnfci="NF"
xarq:="notam"
else
xarq:="notam_ci"
endif
(xarq)->(dbsetorder(1))
(xarq)->(dbseek(xdocum))
do while (xarq)->docum = xdocum .and. ! (xarq)->(eof())
if custo_fixa_doc->(dbseek( (xarq)->docum + xnfci+ (xarq)->codprod ))
// verifico se tem nao arquivo que fixa o custo
// tirando este teste aqui cai para 1 minuto e meio
// aqui eu testo se no arquivo custo_fixa_doc se o ussuario digitou o produto que não é para mudar o custo.
// quando nao existe custo por exemplo.
xcustoDoc+=custo_fixa_doc->vlcusto* (xarq)->qtd
else
xcustoprod:=fcustoProdx( (xarq)->codprod,(xarq)->emissao)
xcustoDoc+=xcustoprod* (xarq)->qtd
endif
(xarq)->(dbskip())
enddo
retu (xcustodoc)
harbour 3.2 dev(r1510132105)
minigui extend 2.5.4.2015.10.21
DBF CDX
Faz o seguinte, melhora o filtro, testa e posta aqui pra dizer se deu certo.
é rede mapeada ? etc...
Deve ser DBF,,,,
- Criar Ãndices pra agilizar
- usar hbnetio e processar relatório no servidor
- processar relatório no servidor
- deixar relatórios prontos a noite
- etc.
Isso é problema de rede. E se for WIFI piora.
Dica: Se placas de rede, roteadores e hubs forem de mesma marca melhor ainda.
Tenta ver se a configuração da placa de rede tá Full ou half duplex, ou seja uma rede que é 100 MB é placa tá trabalhando como 10 Mbps
vc usa dbf temporarias? para gerar esse relatório??
ou é direto da dbf?
Quando vi que doideira seria trocar meus Set Filters sofisticados quase parei. Mas como já vinha usando o OrdScope() a contendo em meus aplicativos DOS pensei:
EU ao pesquisar produtos la na venda faço:
o nome do produto ou Partes do nome separados por (:) === .or. ou por (;) === .and.
Acesso pela rede SEMPRE é mais lento do que local.
USEM O SQL COMO BASE.
tempofat->(dbgotop())
do while ! tempofat->(eof())
*--------------calculo o valor do documento
*------------------------------------------
vvlCusto:=fcustoDocum(vdocum,vnfci) // a demora no terminal esta aqui
*---------------------------------
tempofat->(dbskip())
enddo
FUNC fcustoDocum(Xdocum,xnfci)
// calcula o custo total do documento, produto por produto
local xarq, xcustoProd:=0,xcustoDoc:=0 , xabre:=.f. , mx:={}
if ! xnfci $ "NF-CI"
MSGSTOP("erro na funcao fcustodocum, consulte a assitencia")
retu xcustodoc // retorno 0 mesmo
endif
if xnfci="NF"
xarq:="notam"
else
xarq:="notam_ci"
endif
(xarq)->(dbsetorder(1))
(xarq)->(dbseek(xdocum))
do while (xarq)->docum = xdocum .and. ! (xarq)->(eof())
if custo_fixa_doc->(dbseek( (xarq)->docum + xnfci+ (xarq)->codprod ))
// verifico se tem nao arquivo que fixa o custo
// tirando este teste aqui cai para 1 minuto e meio
// aqui eu testo se no arquivo custo_fixa_doc se o ussuario digitou o produto que não é para mudar o custo.
// quando nao existe custo por exemplo.
xcustoDoc+=custo_fixa_doc->vlcusto* (xarq)->qtd
else
xcustoprod:=fcustoProdx( (xarq)->codprod,(xarq)->emissao)
xcustoDoc+=xcustoprod* (xarq)->qtd
endif
(xarq)->(dbskip())
enddo
retu (xcustodoc)
FUNC fcustoProdx(XCOD,xdata)
/*
arquivo produto_prVenda.dbf está na ordem de codigo + data + hora, minuto e seg
neste arquivo são registrados os preços de custo manualmente pelo usuario.
*/
local xcodEncontrado,xCustoEncontrado, xcodAnterior,xCustoAnterior
produto_prVenda->(dbseek(xcod+dtos(xdata+1),.t.))
//
xcodEncontrado:=produto_prVenda->codigo // para testar se anterior não for o pesquisado
xCustoEncontrado:=produto_prVenda->pr_custo
//
produto_prVenda->(dbskip(-1))
xcodAnterior:=produto_prVenda->codigo
xCustoAnterior:=produto_prVenda->pr_custo
//
if xcodAnterior= xcod // o codigo anterior é = o pesquisado , estou no ultimo é o correto
xcusto:=xcustoAnterior
elseif xcodEncontrado = xcod // é o encontrado, mesmo que nao seja a data utilizo este, para nao ficar sem custo
xcusto:=xcustoEncontrado
else
xcusto:=0 // nenhum custo encontrado
endif
retu (xcusto)
tempofat->(dbgotop())
do while ! tempofat->(eof())
*--------------calculo o valor do documento
*------------------------------------------
vvlCusto:=fcustoDocum(vdocum,vnfci) // a demora no terminal esta aqui
*---------------------------------
tempofat->(dbskip())
Hrb_DoEvents() //<<======
enddo
#pragma BEGINDUMP
#include "windows.h"
#include "hbapi.h"
#include "olectl.h"
#include "time.h"
HB_FUNC( HRB_DOEVENTS )
{
MSG Msg;
while( PeekMessage( ( LPMSG ) &Msg, 0, 0, 0, PM_REMOVE ) )
{
TranslateMessage( &Msg );
DispatchMessage( &Msg );
}
}
#pragma ENDDUMP
Essa dança é antiga... e não vi nada que resolva... diretamente no harbour..
Se fosse GTWVG, indicaria pra acrescentar um Inkey() dentro dos DO WHILE.
Se o processo for muito rápido, não dá tempo do Windows fazer a parte que precisa.
Como não é, talvez DO EVENTS ou algo assim.
Por acaso a tela do relatório chega a congelar?
já pensou em modificar de dbf temporária
para usar vetores?
Eu tentaria o uso do events como o Quintas mencionou, já tive esses problemas de lentidão no processamento e foram resolvidos com hwg_doevents
Venho sempre questionando aqui para quem usa "NetIo", LetoDB e Sql, se a velocidade é comparada ao TS.. a resposta teste...
O Poka se bem souber instala o LetoDbf ai e vai ser só alegria nunca mais vai se preocupar com lentidão no DBF.
Usuários vendo este fórum: Google [Bot] e 10 visitantes