Testando LetoDB

[Itamar M. Lins Jr.]

Ola lista!

Estou criando um projeto usando o LetoDB.
Estou usando a hwgui como lib gráfica.

Achei um problema aqui, está com limite de apenas 5 conexões simultaneas e só fecha (encerra) a conexão depois que termino o executável.

No mais os comando estão funcionando, use,index,seek,locate, foram os que já testei.
Não estou gostando da velocidade em rede com IP local está igual a rede com ip publico.

Saudações
Itamar M. Lins Jr.

[rochinha]

Amiguinho

Se possivel disponibilize uma demonstração com .DBF, clientes e servidor da forma como estão pois já podem nos dar uma visão.

A partir dai poderemos ter mais idéias.

[sygecom]

Rochinha a LetoDB ainda é muito recente e tem algums problemas alinda ! Nos meus teste o alguns comandos de DBFCDX " como OrdBagName() e OrdKeyCount() apresentou alguns erros. E ela não compila no xharbour 9970, aqui apenas consegui compilar com a versão da CVS. Assim que der vou disponibilizar uns exemplo de acesso de DBF remoto.

[sygecom]

Ola lista!

Estou criando um projeto usando o LetoDB.
Estou usando a hwgui como lib gráfica.

Achei um problema aqui, está com limite de apenas 5 conexões simultaneas e só fecha (encerra) a conexão depois que termino o executável.

No mais os comando estão funcionando, use,index,seek,locate, foram os que já testei.
Não estou gostando da velocidade em rede com IP local está igual a rede com ip publico.

Saudações
Itamar M. Lins Jr.

Itamar isso é um projeto recente e no meu ponto de vista ainda não podemos ter uma analise geral da LIB, sobre desempenho e compatibilidade. Tenho acompanhado a LetoDB quase que todos os dias e ela esta sofrendo alterações quase que diariamente, quem sabe da qui uns dias ela já possa ser usada em produção.
Sobre o seu problema já foi adicionado a "leto_Disconnect()" que fecha as conexões abertas.

[runner]

Ola, estou interessado tambem neste novo recurso.


Encontrei um material interessante para pesquisa neste link abaixo. Se ajudar alguem que esta como eu comecando a trabalhar com LETODB.


http://xbasesuporte.freeforums.org/dica ... t-t54.html :)Pos

[Itamar M. Lins Jr.]

Ola, estou interessado tambem neste novo recurso.


Encontrei um material interessante para pesquisa neste link abaixo. Se ajudar alguem que esta como eu comecando a trabalhar com LETODB.


http://xbasesuporte.freeforums.org/dica ... t-t54.html :)Pos

Esse forum só podemos ver as mensagens se nos cadastrarmos, eu tó de saco cheio de anuncios desse forum, porque ficar dividindo os foruns ?
Tudo que é pergunta agora vem propaganda desse forum...
Deveria o pessoal do pctoledo tomar providencias...

Saudações
Itamar M. Lins Jr.

[Luciano Bonfim]

acredito que toda informaçäo que venha contribuir seja válida, vindo ela de onde vier. Näo sei quem criou esse outro fórum, mas fiz o cadastro nele e visualizei o conteúdo acima.

Muito Obrigado

[Itamar M. Lins Jr.]

Itamar isso é um projeto recente e no meu ponto de vista ainda não podemos ter uma analise geral da LIB, sobre desempenho e compatibilidade. Tenho acompanhado a LetoDB quase que todos os dias e ela esta sofrendo alterações quase que diariamente, quem sabe da qui uns dias ela já possa ser usada em produção.
Sobre o seu problema já foi adicionado a "leto_Disconnect()" que fecha as conexões abertas.

É mais "eu" já uso sem medo, porque considero seus desenvolvedores excelentes profissionais. O PAI da HWGUI/HARBOUR junto com o PAI do OURXDBU é mole?

Mesmo con esse problema que diga-se de passagem já foi corrigido, a performase tambem tá boa mesmo. Num link ADSL de 300 kbps.

Ps.
Só falta o Mala digo Maligno assumir o posto dele, exímio programador que é, entrar para o time de desenvolvedores do [x]harbour


Saudações
Itamar M. Lins Jr.

Veja mais implementações e teste de performase.

Código: Selecionar todos

https://sourceforge.net/forum/message.php?msg_id=4834626
By: alkresin

There are two threads already, see the latest Changelog.
One thread accepts connections, waits for and reads all incoming requests and
replies to those of them, which doesn't demand database access. Other thread
handles all database related requests. Such model is implemented, because Harbour
doesn't support mt yet and it isn't possible to have few threads, working with
Harbour's stack, VM, RDD - so the second thread only works with all these, while
the first uses pure C ( not the Harbour RTL ) code.

Thus, handling of any database request ( independently of which dbf, the same
or not ) is performed sequentially, one after another. The time of server answer
doesn't depend on which dbf is used by different users. Of course, if one client
program will, for example, reindex a huge dbf, all other clients will wait for
a remarkable time; if there is usual activity - skipping, seeking, updating
records, there will not be visible delay. I've run ~20 client test programs,
each of them opens ~30 dbfs and once in a second performs some action ( skipping
20 records, close/open table, etc. ) and all this activity results in 1-2% CPU
loading on a server ( Pentium IV, 3000 GHz ) and ~5% increasing the time of
a huge test ( updating, skipping dbf ).

Anyhow, I plan to introduce separate processes, which will handle most time
consuming requests, such as indexing.

[sygecom]

Itamar, vc tem toda a razão o RDDLETO é muito bom e funciona muito bem, fiz um pequeno sisteminha usando LETO, agora vou me aprofundar mais utilizando rotinas mais complexa. vlw...

Abraços
Leonardo Machado

[alaminojunior]

Ps.
Só falta o Mala digo Maligno assumir o posto dele, exímio programador que é, entrar para o time de desenvolvedores do [x]harbour [/code]

Se prepara para a resposta ! Claro sempre muito técnica, precisa e contundente.