16 Nov 2020 07:42
16 Nov 2020 08:10
nsar nisso, de usar LetToDbf ou SQL, porque quando é só o servidor que mexe nos arquivos, fica
********************************
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
16 Nov 2020 09:11
16 Nov 2020 10:33
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.
16 Nov 2020 16:54
) 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,
você mencionou, que não tem como perder conexão, preciso saber como, o LETODB, é muito fácil de implementar em qualquer Sistema,
16 Nov 2020 17:14
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()
17 Nov 2020 05:33
17 Nov 2020 13:03
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
Client library:
-- all OS: hbmk2 rddleto
Recommended is to integrate LetoDbf client library into your Harbour environment as an 'addon':
-- all OS: hbmk2 rddletoaddon
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
18 Nov 2020 07:33
18 Nov 2020 08:10
c:\letodbf\bin\letodb.exe install
net stop letodbf_service
sc delete letodbf_service
18 Nov 2020 08:25
Desculpe pelo "furo", realmente pensei que o LETODB, fosse o mesmo,
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 !
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 ...
18 Nov 2020 15:54
19 Nov 2020 07:37