1) Pra usar no modo harbour, precisa perguntar no harbour-users, com certeza tem gente que usa.
Lembro de já ver mensagens lá de quem usa com comandos SQL.
Depende de baixar coisas e acertar a compilação dessa contrib.
2) Outra opção é o SQLMIX e ODBC, tem pra Linux e Windows
Mesma coisa: precisa ver com quem usa isso
3) Usando ADO
Isso é padrão pra qualquer conector, seja DBF, MySQL, PostGre, SQL Server, SQLite.
Precisa baixar o conector do fabricante, e instalar no Windows.
No cnSQL vai indicar a string de conexão, que tem que bater com o nome do que foi instalado, e os parâmetros de IP, Path, ou o que precisar conforme o conector.
Da última vez que testei, usei esta conexão
Código: Selecionar todos
FUNCTION ADSConnection( cPath )
LOCAL oConexao := win_OleCreateObject( "ADODB.Connection" )
oConexao:ConnectionString := "Provider=Advantage OLE DB Provider;" + ;
"Mode=Share Deny None;" + ;
"Show Deleted Records in DBF Tables with Advantage=False;" + ;
"Data Source=" + cPath + ";Advantage Server Type=ADS_Local_Server;" + ;
"TableType=ADS_CDX;Security Mode=ADS_IGNORERIGHTS;" + ;
"Lock Mode=Compatible;" + ;
"Use NULL values in DBF Tables with Advantage=True;" + ;
"Exclusive=No;Deleted=No;"
oConexao:CursorLocation := AD_USE_CLIENT
oConexao:CommandTimeOut := 20
RETURN oConexao
A partir daí, só usar a conexão pra tudo.
Teste leve não tem graça, faça teste pesado.
Do tipo que usa vários arquivos, vários relacionamentos, filtros, agrupamentos
Vão ser usados seus DBFs e seus índices CDX compatíveis, sendo que os índices serão desprezados se não forem compatíveis.
Índices não são obrigatórios, mas se puderem ser aproveitados vão tornar o resultado mais rápido.
Como exemplo, vamos supor um financeiro, que usa código de cliente e código de portador
Código: Selecionar todos
// campos a selecionar indicando origem
cSQL := "SELECT NUMDOC, EMISSAO, VENCTO, SUM(VALOR) AS SOMA, FINANC.CODCLI AS FINCLI, CLIENTE.NOME AS CLINOME, FINANC.CODPORT AS FINPORT, PORTADOR.NOME AS PORTNOME"
// arquivo principal de onde vém a informação
cSQL += " FROM FINANC"
// relacionamento entre tabelas pelo código
cSQL += " LEFT JOIN CLIENTE on CLIENTE.CODCLI = FINANC.CODCLI
cSQL += " LEFT JOIN PORTADOR on PORTADOR.CODPORT = FINANC.CODPORT
// algum filtro
cSQL += " WHERE VALOR < 10000"
// agrupamento (totais)
cSQL += " GROUP BY FINANC.CODCLI, FINANC.CODPORT"
// ordem desejada
cSQL += " ORDER BY CLINOME, PORTNOME"
oResultado := cnSQL:Execute( cSQL )
DO WHILE ! oResultado:Eof()
?? oResultado:Fields( "NUMDOC" ):Value
?? oResultado:Fields( "EMISSAO"):Value
?? oResultado:Fields( "VENCTO" ):Value
?? oResultado:Fields( "SOMA" ):Value
?? oResultado:Fields( "FINCLI" ):Value
?? oResultado:Fields( "CLINOME" ):Value
?? oResultado:Fields( "FINPORT" ):Value
?? oResultado:Fields( "PORTNOME" ):Value
?
cnSQL:MoveNext()
ENDDO
oResultado:Close()
Com ADO já tem tudo que precisa, menos o ODBC, instalou pronto.
Com as opções do harbour.... boa sorte... vai pesquisando/perguntando, daqui uma semana ou mais talvez tenha descoberto o que precisa, e em menos de um mês pode começar a testar.
Ok, aí acima é ADO puro, sem nenhuma rotina pra facilitar.
Se facilitar, pode comparar o uso acima com DBF:
FINAN.CODCLI é similar a FINAN->CODCLI
LEFT JOIN CLIENTE ON FINAN.CODCLI = CLIENTE.CODCLI
seria similar a
SET RELATION TO FINAN->CODCLI INTO CLIENTE
onde cliente seria indexado por CLIENTE->CODCLI
WHERE VALOR < 1000
é similar a
SET FILTER TO VALOR < 1000
GROUP BY FINAN.CODCLI, FINAN.CODPORT
similar ao pouco usado
TOTAL ON ...
ORDER BY CLINOME, PORTNOME
similar a
INDEX ON CLINOME + PORTNOME
Por último, mas não menos imortante
FINANC.CODCLI AS FINCLI, CLIENTE.NOME AS CLINOME, FINANC.CODPORT AS FINPORT, PORTADOR.NOME AS PORTNOME
Imagine criar um temporário.
Não vai poder ter dois campos chamados NOME, por isso aqui renomeados pra CLINOME e PORTNOME
CODCLI iria existir no financeiro, no cliente, e também no resultado, se definir nos filtros CODCLI ficaria confuso saber qual dos 3 está se referindo por isso obriga a detalhar mais
No temporário iria usar REPLACE CLINOME WITH CLIENTE->NOME
é o que está indicando no SQL: CLIENTE.NOME AS CLINOME
É questão de acostumar, mas é o que sempre usamos, mas não escrevendo exatamente como costumamos fazer.
Um comando desses, ou mais avançado ainda que é legal de testar.
O que interessa é a velocidade de processamentos pesados, testar ler/gravar um registro não é teste que se faça pra isso.
De preferência arquivos com milhares de registros, que demoraria pra fazer em acesso de DBF normal.
Talvez totais de cada cliente por mes, etc
ISSO TAMBËM NÃO É TESTAR VELOCIDADE DE ADO.
Não confunda, o ADO é só um intermediário, que vai deixar as coisas no formato ADO.
O trabalho é feito pelo ODBC, ou nos casos onde existe um servidor, pelo servidor.
Se gostar da velocidade/resultado, aí vai atrás se quiser usar o RDDADS, ou SQLMIX ou outro.
Acho que a parte mais importante aqui é ver se realmente é mais rápido.
Se for usar os outros, vai perder tanto tempo pra configurar, que pode até desistir.
Já vendo resultado rápido, e testando velocidade, nem vai se importar se demorar pra configurar os outros.
Imagino que o resultado seja tào rápido quanto ADO, mas aí, vai ter que fazer seus próprios testes.
A vantagem (*) seria aproveitar fonte DBF, mas a desvantagem seria ficar pensando que é DBF.
Não parece, mas isso faz diferença pro cérebro.
Pode pensar que select * e filtro usando SKIP seja uma solução boa, quando é lixo, atraso de vida, deveria trazer o resultado pronto sem precisar processar.
Se não encontrar o ODBC do ADS tenho aqui.
DBF vai sumindo da internet, ainda mais quando é de graça.
Convém também chamar a atenção, muita gente confunde.
ADS é Advantage Database Server.
É um produto, onde existe o uso de Servidor, e custa muito caro.
Advantage Local Server é o uso SEM SERVIDOR, com ou sem rede.
Pra isso não precisa servidor, e não precisa pagar nada, é grátis.
Mesmo sendo grátis, vém com limite de 20 usuários.
Não sei dizer se o limite são 20 usuários fazendo uso, ou 20 usuários conectados, ou se o fabricante poderia informar como aumentar esse limite.
