PC Toledo

Para demonstrar as capacidades do HBDBD, fiz esse pequeno programa chamado hbsql, que eh um "sql tool".
A sua única função, por enquanto, é executar queries.
O funcionamento é bem simples:
hbsql <driver> <file>

onde:
<driver> número do driver: 0-POSTGRESQL, 1=SQLITE, 2=MYSQL (não implementado aki ainda)
<file> arquivo texto, contendo uma string de conexão completa e funcional, não faz qualquer "parser" aki.

hbsql:
parte de cima, editor (memoedit) de SQL, basta digitar e teclar CTRL + W
parte de baixo, browser dos registros ou tela de resultado da querie.

Limitações:
MySQL (ainda não implementado)
Limitado a 24 colunas ou campos, (não mostra mais), será ampliado. Esse limite é pq o "codeblock" está
"hardcoded' no fonte.

Quem tiver uma base PosgreSQL realmente grande e puder testar, poste alguma consulta aki.
Em um teste com uma tabela de 15000 registros está levando 0.06 (secs), menos de 1 segundo. Entre a execução, leitura e apresentação dos 15000 registros pelo browser. A base é local, ou seja, tudo na mesma máquina.
O tempo é calculado pela diferença da função seconds().

O link para baixar é do Google Drive:
... K5cu2mrwhO

hbsql.exe (32bits, windows, harbour 3.2)

Qualquer problema, favor avisar.

Ranier escreveu:Em um teste com uma tabela de 15000 registros está levando 0.06 (secs), menos de 1 segundo.

Por coincidência, dá pra considerar que neste instante estou fazendo um teste pesado.
São 20 partes, a que está processando agora tem 1.7 milhões de registros.
Quase 40 milhões de registros sendo gravados.

Ainda faltam essas 14 partes
Foi aí que notei que.... Harbour 32 bits está com os dias contados, porque estaria limitado a 4GB.

Alguém aí tem alguma idéia se isso pode ser considerado rápido ou não?

Meu servidor é simples, 4GB de memória, já que é só de meu uso.

Estou incluindo registros, e nem sequer deu tempo do MySQL atualizar ali o tamanho.
Do post anterior pra agora, incluiu uns 4 milhões de registros.
Durante o post terminou mais um, então a quantidade é por aí.
Usando ADO e, lógico, não é um registro por vez.

"Por favor, poste alguns exemplos do conteudo do arquivo de conexão, estou tentando com sqlite mas sem sucesso:"

sqlite.ini:
c:\usr\src\hbdbd\hbsql\tests.db

hbsql 1 sqllite.ini

"https://www.connectionstrings.com/sqlite/"
Acredito que os examplos são Sqlite.Net

O hbsql não faz qualquer parser, por enquanto, então a string de conexão deve obedecer a :
sqlite3_open (https://www.sqlite.org/c3ref/open.html)

"Foi aí que notei que.... Harbour 32 bits está com os dias contados, porque estaria limitado a 4GB."
Com certeza, para grandes bancos de dados o servidor não pode ser 32bis. Mas para os clientes, ainda resolve.
Claro, não têm como baixar uma tabela de mais de 4GB, pro desktop.
Mas, trabalhar com tabelas de 15000 registros em memória, é bem factível, para clientes 32 bits.

O HBDBD, terá versões 32 e 64 bits. Então num cliente Windows 10 64bits, com 16GB de memória, mais HD como swap, terá como trazer uma tabela de 8GB, mas não fiz tal teste ainda.

Com relação ao seu teste, me parece que vai levar 10m e 52s, seria isso?

Correção, o tempo calculado se refere somente ao executar a querie e trazer os resultados em array. E não inclue a apresentação.

Outro teste:
Postgresql 32 bits
tabela com 618055 registros
tempo: 1.28s, um segundo e 28 milisegundos.

Existe outro contador de tempo mais confiável em Harbour que Seconds()?

Ranier escreveu:Existe outro contador de tempo mais confiável em Harbour que Seconds()?

Em Windows nenhum é confiável, o tempo é sempre compartilhado.
O mesmo teste trás resultados diferentes.

"Encontrei um problema, quando na primeira row tem alguma coluna vazia, então essa coluna ficará de fora para todo o resto..."
Ok. Corrigido.

Nova versão:
Limite de 64 colunas.

Novo Link:
... BX2fNrILpi

Sinto muito, problema corrigido, eu acredito.
Otimização prematura.

Novo link:
... ENigkLJuGl

hazael escreveu:Agora não deu erro, mas ainda não mostra colunas que estejam vazias, isso baseado na primeira row:

Problema corrigido. Como sempre o gerenciamento de NULLS em SQL sempre complica.

Novo link:
https://drive.google.com/open?id=1pZmv6 ... syptfPudRj

Link testado e funcionando.
https://drive.google.com/open?id=1pZmv6 ... syptfPudRj

Link OK mas não mudou nada com relação aos campos, eles não são NULL, são apenas vazios:

Teria como você disponibilizar o "schema" da tabela.

No meu teste aki o "schema" da tabela eh:
CREATE TABLE tbcad (cad_uid INTEGER, FULL_NAME VARCHAR(64), STATUS CHAR(1), PRIMARY KEY (cad_uid));
Na tabela existe somente uma linha, onde:
cad_uid = 1
FULL_NAME = NULL
STATUS = 'A'

Fiz uma versão "debugável", teria como você postar um print do conteúdo da primeira linha das variáveis aFIELDS e aROWS?
Pelo menu Monitor.
Obrigado.

Link:
https://drive.google.com/open?id=1ZXGdR ... ANJBYhRrsD

O Sqlite tem suas peculiaridades. Nesse caso da tabela datacep, o "schema" utiliza o "datatype" TEXT, que conforme documentação do Sqlite, pode armazenar qualquer quantidade de strings ou textos, tanto zero ou 1gb por exemplo.
Entretanto a api do Sqlite não fornece qualquer recurso para se saber qual o "tamanho" do campo TEXT, então a informação que temos é essa: aFIELDS[3] retorna o "tamanho" do campo, zero nesse caso.
Podemos ver na primeira linha, que os valores estão lá zerados.
Dessa forma, ficou a responsabilidade da apresentação dos dados, pelo usuário da HBDBD. A única forma de se saber qual o "tamanho máximo", dos campos zerados, é lendo linha a linha e comparando se é o maior tamanho, tarefa muito lenta.

dbws.prg, faz um tentativa simplória de saber qual o tamanho a ser apresentando.