PC Toledo

É nisso que o SQLRDD do xHarbour ajuda, vc migra sua aplicação pra SQL mantendo inicialmente os comandos normais, e aos poucos vai convertendo os relatórios mais críticos pra comandos SQL, e na sequência vai convertendo o resto que precisar, por isso adoraria que os caras liberassem rápido os fontes pra algum portar para o harbour, mas o Ron Pinkas tá enrolando bastante já.

marco.prodata escreveu:É nisso que o SQLRDD do xHarbour ajuda, vc migra sua aplicação pra SQL mantendo inicialmente os comandos normais, e aos poucos vai convertendo os relatórios mais críticos pra comandos SQL, e na sequência vai convertendo o resto que precisar, por isso adoraria que os caras liberassem rápido os fontes pra algum portar para o harbour, mas o Ron Pinkas tá enrolando bastante já.

Tem uma coisa muito importante a ser analisada:
Trabalhar como DBF em SQL, é deixar tudo mais lento.
Migração rápida, para o programador é o máximo, porque está usando SQL, tá melhor.
Para o cliente... tá tudo mais lento.. é o mínimo e não o máximo, tá pior.

A questão é:

Por quanto tempo o cliente vai ficar pior do que antes?
Ele vai aceitar isso numa boa?
Pode ser que sim, mas pode ser que não, cada um precisa avaliar isso também, porque não é igual pra todos.
Se está com a corda no pescoço e não tomar cuidado, pode se enforcar de vez.

Bom dia.

Obrigado pelos comentários, sempre ajudam.

Quintas, se bem me lembro tem um exemplo seu de uso do ADS, num programa de leitura de playlists de música, não?

Nos SGBD tradicionais, tem as rotinas de conexão e desconexão, no ADS não faço ideia de como seja, se pode dar comandos diretos de SQL, depois que instalar no ODBC. Ou tem uma forma particular de ativar o ADS?

As queixas de alguns nem sempre são causa direta dos DBFs. São tabelas muito pequenas comparadas com o poder do SQL, creio que seja em parte uma mistura de máquinas velhas, windows piratas mal instalados, zero manutenção, monte de programas abertos, uma soma de coisas que degradam o uso em rede. Acho que não tenho uma tabela com um milhão ou mais de registros. Para hoje em dia, é pequeno porte. Nada que DBF não dê conta...

Mas de qualquer forma, o interesse em SQL vale pois, como vemos, não podemos só depender do Harbour pra tudo e ficar restrito aos DBF limita o uso de ferramentas externas.

Saudações,
Mario.

Mario Mesquita escreveu:Quintas, se bem me lembro tem um exemplo seu de uso do ADS, num programa de leitura de playlists de música, não?

Aquele do playlist é SQLite, usando ADO, mas SQLite.
Qualquer exemplo ADO vale pra qualquer coisa.
De um modo geral, o que altera é a string de conexão, e instalar o ODBC, outro intermediário, conforme o banco de dados.
Só dá pra saber se isso existe se não estiver instalado, porque vai dar erro que a "fonte de dados" é desconhecida.

JoséQuintas escreveu:

marco.prodata escreveu:É nisso que o SQLRDD do xHarbour ajuda, vc migra sua aplicação pra SQL mantendo inicialmente os comandos normais, e aos poucos vai convertendo os relatórios mais críticos pra comandos SQL, e na sequência vai convertendo o resto que precisar, por isso adoraria que os caras liberassem rápido os fontes pra algum portar para o harbour, mas o Ron Pinkas tá enrolando bastante já.

Tem uma coisa muito importante a ser analisada:
Trabalhar como DBF em SQL, é deixar tudo mais lento.
Migração rápida, para o programador é o máximo, porque está usando SQL, tá melhor.
Para o cliente... tá tudo mais lento.. é o mínimo e não o máximo, tá pior.

A questão é:

Por quanto tempo o cliente vai ficar pior do que antes?
Ele vai aceitar isso numa boa?
Pode ser que sim, mas pode ser que não, cada um precisa avaliar isso também, porque não é igual pra todos.
Se está com a corda no pescoço e não tomar cuidado, pode se enforcar de vez.

Então, migrei vários sistemas pra SQL usando o SQLRDD, e ai é o seguinte, o processo de seek e replace, é igual o tempo, o que muda são os relatórios, os do whiles da vida que ficam bem mais lentos, então eu sempre pego os principais relatórios e rotinas de processamento mais pesados e converto pra usar comandos SQL, é mantenho as telas de cadastro com seek replace, e depois vou alterando as mesmas aos poucos, e os clientes na verdade acham até muito mais rápido, pois as rotinas cruciais são convertidas pra SQL antes da implantação da conversão, há um ganho de tempo enorme, ao invés de já ter que converter todo o sistema pra usar comandos SQL.

Bom dia a todos.

Quintas, entendi. Então não tem um exemplo prático de uso do ADS no site? Ou é só fazer uma abertura padrão (se é que isso existe, rs)?

De fato, acho que usei aquele post para fazer uns testes com SQLite. Achei legal, mas cai no mesmo caso dos outros, migrar tudo, criar tabelas, etc.

Ainda acho a ideia de usar o ADS como transição bem interessante.

Saudações,
Mario.

Mario Mesquita escreveu:Quintas, entendi. Então não tem um exemplo prático de uso do ADS no site? Ou é só fazer uma abertura padrão (se é que isso existe, rs)?
De fato, acho que usei aquele post para fazer uns testes com SQLite. Achei legal, mas cai no mesmo caso dos outros, migrar tudo, criar tabelas, etc.
Ainda acho a ideia de usar o ADS como transição bem interessante.

Depende do conector.
Se vai testar o ADO, é abrir a conexão no início do aplicativo, e fechar no final.

Uma diferença básica, que NÃO SEI SE AINDA EXISTE, é ao limitar quantidade de registros.
De resto é igual a qualquer SQL.

SELECT TOP 1 codigo, nome FROM tabela
SELECT codigo, nome FROM tabela LIMIT 1

Comparo muito o SQL com mensagens do whatsapp, enviar mensagem com comando, e retorna resultado.

Incluir, que não vai usar agora:
INSERT INTO tabela ( codigo, nome ) VALUES ( 1, 'jose' )

alterar, que não vai usar agora:
UPDATE tabela SET nome='jose' WHERE codigo=1

excluir, que não vai usar agora:
DELETE FROM tabela WHERE codigo=1

consultar, isso vai longe, dá pra fazer a mesma coisa de várias formas, pode depender de estrutura sem nome repetido,etc:

tudo de um codigo:

SELECT * FROM tabela WHERE codigo=1

algumas informações de uma UF:

SELECT codigo,nome FROM tabela WHERE cidade='SP'

pegando do financeiro, e trazendo o nome do cadastro, para uma condição específica, e em ordem alfabética

SELECT idfinanceiro, fincliente, nome
FROM financeiro
INNER JOIN clientes ON financeiro.fincliente = clientes.idcliente
WHERE dtvencto < '2023-01-20'
ORDER BY nome

totalizado por codigo, em ordem alfabética

SELECT fincliente, nome, SUM( VALOR )
FROM financeiro
INNER JOIN clientes ON financeiro.fincliente = clientes.idcliente
WHERE dtvencto < '2023-01-20'
GROUP BY fincliente
ORDER BY nome

Os comandos SQL tem a ver com o SERVIDOR, em qualquer conector vão ser os mesmos comandos.
No caso do ADS, é igual, só não tem servidor nesse uso só do ODBC

Como exemplo de ADO, que é o que uso e conheço, na rotina:

oResultado := cnSQL:Execute( comando )
...
oResultado:Close()

Qualquer dos comandos acima, é só executar.

Também pode avaliar o uso de SQLMIX, já que vai estar usando DBF, e só altera o resultado, vão ser os mesmos comandos.
Uma das opções do SQLMIX é usar ODBC, que é o que vai usar
Tudo depende de teste, seja qual for a opção. Só ouço falar, nunca usei.

Também tem no HARBOUR 3.2 o ADORDD (ou RDDADO). Usei pouco em pequenos testes.

São muitas opções, mas os comandos SQL são sempre os mesmos.
Apenas se baseie nisto: tá aprendendo a usar comandos SQL, tá valendo, não tá perdendo nada.
Se um não for o que espera, troque por outro, e continue usando os mesmos comandos SQL, não perdeu nada do que foi aprendendo.