Clipper On Line • Ver Tópico - Teste de SQL com DBF
Página 1 de 4

Teste de SQL com DBF

MensagemEnviado: 14 Jan 2020 00:57
por JoséQuintas
Infelizmente, não serve como modelo pronto, porque depende dos arquivos, e os arquivos contém informações particulares, então não vou fornecer arquivos.
É apenas pra mostrar possibilidades.

#include "inkey.ch"

PROCEDURE Main

   LOCAL oConexao, oRs

   oConexao := ConexaoMySql( "d:\jpa\cordeiro" )
   oConexao:Open()
   SetMode(40,100)
   CLS
   oRs := oConexao:Execute( "SELECT " + ;
      " IDPEDIDO," + ;
      " JPNOTFIS.NFNOTFIS AS NOTFIS, " + ;
      " JPCADASTRO.CDNOME AS CADNOME, " + ;
      " JPFINAN.FIDATVEN AS DATVEN, " + ;
      " JPFINAN.FIVALOR AS VALOR, " + ;
      " JPITPED.IPITEM AS ITEM, " + ;
      " JPITPED.IPVALNOT AS VALNOT," + ;
      " JPITEM.IEDESCRI AS ITEMNOME" + ;
      " FROM JPPEDIDO" + ;
      " LEFT JOIN JPNOTFIS ON JPNOTFIS.NFPEDIDO=JPPEDIDO.IDPEDIDO" + ;
      " LEFT JOIN JPCADASTRO ON JPCADASTRO.IDCADASTRO=JPPEDIDO.PDCLIFOR" + ;
      " LEFT JOIN JPFINAN ON JPFINAN.FIPEDIDO=JPPEDIDO.IDPEDIDO" + ;
      " LEFT JOIN JPITPED ON JPITPED.IPPEDIDO=JPPEDIDO.IDPEDIDO" + ;
      " LEFT JOIN JPITEM ON JPITEM.IDITEM=JPITPED.IPITEM" + ;
      " WHERE PDDATEMI BETWEEN '2019-12-01' AND '2019-12-10'" )
   WITH OBJECT oRs
      DO WHILE ! :Eof()
         ?? oRs:Fields( "IDPEDIDO" ):Value
         ?? oRs:Fields( "NOTFIS" ):Value
         ?? oRs:Fields( "CADNOME" ):Value
         ?? oRs:Fields( "DATVEN" ):Value
         ?? oRs:Fields( "VALOR" ):Value
         ?? oRs:Fields( "ITEM" ):Value
         ?? oRs:Fields( "VALNOT" ):Value
         ?? oRs:Fields( "ITEMNOME" ):Value
         ?
         :MoveNext()
      ENDDO
      :Close()
   ENDWITH
   oConexao:Close()
   Inkey(0)

   RETURN

FUNCTION ConexaoMySql( 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 := 3
   oConexao:CommandTimeOut := 20

   RETURN oConexao


O comando lista os pedidos, já pesquisando no financeiro, cadastro de clientes, itens de pedido, descrição de produtos, notas fiscais e filtro por data.

É direto do DBF !!!

Tive que apagar os índices atuais, porque acusou chave de indexação inválida.
Provavelmente porque não tem Left() ou alguma coisa parecida, mas caso alguém vá usar, trocaria Left() por Substr() e tudo bem.
Como era teste, nem me preocupei, apenas apaguei os CDX.

NÃO consegui fazer com o ODBC 11, deve ser uma string diferente, mas pra teste nem pesquisei, usei o que tinha aqui.

O ODBC que usei foi com meu antigo instalador:
http://www.josequintas.com.br/arquivos/setupjpa.msi

Mas importante:
O instalador instala ODBC ADS, Capicom e MSXML5 - os componentes de NFE
Infelizmente (ou não), ele remove tudo se deinstalar o setupjpa.
Se usa algum deles, fique sabendo que vai precisar reinstalar ao remover o setupjpa.

Quanto ao comando SQL e nomes de campos, só ajustar para seus DBFs.

Teste de SQL com DBF

MensagemEnviado: 14 Jan 2020 01:09
por JoséQuintas
Faltou dizer:

Os comandos são compatíveis com SQL server, mas nesse caso ficaram exatamente iguais ao do MySQL, porque não usei nada diferente do padrão comum aos dois.
Aceitou até relacionar campo numérico com campo caractere, igual acontece no MySQL.

Tamanho dos arquivos do teste:
pedidos: 160MB
itens de pedido: 174MB
financeiro: 115MB
nota fiscal: 232MB
itens: 1.3MB

Usei apenas local, coisa de 1 segundo pra mostrar o resultado.
Tem informação desde 2008 até 2020, cerca de 12 anos de movimentação.
SEM ÍNDICES, somente os DBFs !!!

Teste de SQL com DBF

MensagemEnviado: 14 Jan 2020 11:32
por Marcos Kieron
mas... ADS já existe a quase 30 anos e somente agora é que você viu isso?

Teste de SQL com DBF

MensagemEnviado: 14 Jan 2020 13:32
por JoséQuintas
Marcos Kieron escreveu:mas... ADS já existe a quase 30 anos e somente agora é que você viu isso?


Só repassando pra quem não sabe, e quiser brincar com comandos SQL sem precisar instalar servidor.

Teste de SQL com DBF

MensagemEnviado: 15 Jan 2020 11:44
por Marcos Kieron
Entendi, bom eu não uso ADS, sei que é muito rápido, mas sugiro passar direto para SQL, se for algo muito grande um Postgress mas em geral melhor usar MySQL ou MariaDB que vai resolver 99,9999% dos casos.
Se for algo local, então nem perde tempo, o SQLite vai fazer muiiiiiiito e não precisa instalar ou configurar nada, é a melhor opção local.

Teste de SQL com DBF

MensagemEnviado: 15 Jan 2020 22:33
por JoséQuintas
Só atualizando informação.
É só instalar o OLEDB e mais nada.
Se Harbour 32 bits, instala o 32 bits.
Em XHarbour... não uso... em Harbour, é só usar win_OleCreateObject() da hbwin e mais nada.

https://devzone.advantagedatabase.com/dz/content.aspx?Key=20&Release=19&Product=15

Teste de SQL com DBF

MensagemEnviado: 16 Jan 2020 01:44
por JoséQuintas
Pra uso genérico.
Só compilar e baixar o OLEDB do ADS.

Com certeza vai ficar melhor em LIB gráfica, principalmente pra poder digitar um comando de várias linhas.
MemoEdit() não serve porque inclui caracteres especiais, e Picture @S ajuda mas fica ruim pra conferir o comando.

É digitar o comando SQL e aparece o browse com o resultado.
PRA USAR COM DBFS.

test.png


test.zip
(475.09 KiB) Baixado 262 vezes

Teste de SQL com DBF

MensagemEnviado: 16 Jan 2020 01:58
por JoséQuintas
ado.png

Teste de SQL com DBF

MensagemEnviado: 16 Jan 2020 04:50
por JoséQuintas
Agora com formatação no comando SQL pra ficar no máximo 80 letras por linha
É só pro teste, sem grandes mudanças.
Talvez até o controle multiline da gtwvg fosse melhor, mas.... não tô a fim de mexer nisso.

Totais por cidade

browse.png


test.zip
(476.04 KiB) Baixado 253 vezes


Detalhe do ADS:
Todas as colunas que não são totais, obrigatoriamente precisam aparecer no group by.
Não aceitou duas colunas no left join
Talvez algum detalhe a mais, que só no ADS é necessário.
isso limita, comparado ao MySQL, mas pra aprendizado tá bom, dá pra fazer muita coisa.
Talvez quem mexe com SQL Server saiba, mas pra mim não interessa mais DBF, nem com SQL.

Teste de SQL com DBF

MensagemEnviado: 17 Jan 2020 12:25
por Marcos Kieron
Para mim DBF só se não puder alterar para SQL, não vejo vantagem no DBF em nenhum caso possível

Teste de SQL com DBF

MensagemEnviado: 17 Jan 2020 21:55
por asimoes
Quintas,

estou usando o seu teste.prg

Neste ponto tem como trazer todas as colunas para a grid sem ficar testando?
Tentei passar um for ... next mais não funcionou provavelmente porque o bloco não aceita variável externa para executar
   nQtd := oRs:Fields:Count()
   for i:=0 to nQtd - 1
      AAdd( oTBrowse, { oRs:Fields( i ):Name, { || oRs:Fields( i ):Value } } )
   next

        IF nQTD > 0; AAdd( oTBrowse, { oRs:Fields( 0 ):Name, { || oRs:Fields( 0 ):Value } } ) ; ENDIF
         IF nQTD > 1; AAdd( oTBrowse, { oRs:Fields( 1 ):Name, { || oRs:Fields( 1 ):Value } } ) ; ENDIF
         IF nQTD > 2; AAdd( oTBrowse, { oRs:Fields( 2 ):Name, { || oRs:Fields( 2 ):Value } } ) ; ENDIF
         IF nQTD > 3; AAdd( oTBrowse, { oRs:Fields( 3 ):Name, { || oRs:Fields( 3 ):Value } } ) ; ENDIF
         IF nQTD > 4; AAdd( oTBrowse, { oRs:Fields( 4 ):Name, { || oRs:Fields( 4 ):Value } } ) ; ENDIF
         IF nQTD > 5; AAdd( oTBrowse, { oRs:Fields( 5 ):Name, { || oRs:Fields( 5 ):Value } } ) ; ENDIF
         IF nQTD > 6; AAdd( oTBrowse, { oRs:Fields( 6 ):Name, { || oRs:Fields( 6 ):Value } } ) ; ENDIF
         IF nQTD > 7; AAdd( oTBrowse, { oRs:Fields( 7 ):Name, { || oRs:Fields( 7 ):Value } } ) ; ENDIF
         IF nQTD > 8; AAdd( oTBrowse, { oRs:Fields( 8 ):Name, { || oRs:Fields( 8 ):Value } } ) ; ENDIF
         IF nQTD > 9; AAdd( oTBrowse, { oRs:Fields( 9 ):Name, { || oRs:Fields( 9 ):Value } } ) ; ENDIF
         BrowseADO( oRs, oTBrowse )

Teste de SQL com DBF

MensagemEnviado: 18 Jan 2020 00:32
por asimoes
Consegui:

            WITH OBJECT oRs
               nCol := ( :Fields:Count ) - 1
               FOR i:=0 TO nCol
                  aAdd( oTBrowse, { oRs:Fields( I ):Name, ADORecordSetFieldBlock(oRs, i)} )
               NEXT
               BrowseADO( oRs, oTBrowse )
            END

Teste de SQL com DBF

MensagemEnviado: 18 Jan 2020 09:14
por JoséQuintas
Não colocou a solução, mas é de se imaginar.
Isso pode ser útil pra outras coisas não somente pra esse caso.
Até mesmo GET de array, ou um menu em GUI:

aList := { "A", "B", "C" }
FOR nCont = 1 TO 3
   DoGet( aList, nCont )
NEXT
READ

FUNCTION DoGet( aList, nItem )
 
   @ Row() + 1, 0 GET aLIst[ nItem ]

   RETURN NIL


Qual a diferença?

Se colocar direto na linha do FOR/NEXT não dá certo, porque o valor de nCont não é fixo, parece que vai respeitar o contador, mas na hora do GET o valor é outro.
Já colocando na função, a variável é local, e o valor será fixo.

No codeblock pro ADO é o mesmo esquema.

FOR nCont = 1 TO Rs:Fields:Count()
   RsCodeBlock( Rs, nCont - 1 )
NEXT

FUNCTION RsCodeBLock( Rs, nItem )

   RETURN { || Rs:Fields( nItem ):Value }


Só pra comparação com equivalente DBF, que seria o mesmo caso:

clientes->( FieldGet( nItem ) )

RS:Fields( nItem ):Value

Nota:
No caso do GET foi só exemplo, apesar de dar certo, tem alternativa melhor:
aList := { "A", "B", "C" } 
FOR EACH oElement IN aList
   @ Row() + 1, 0 GET oElement
NEXT
READ

Teste de SQL com DBF

MensagemEnviado: 18 Jan 2020 22:01
por asimoes
Para usar o formato DD/MM/YYYY com o ADS OleDb

hDLL := Hb_libLoad( "ace32.dll" )

nStatus := Hb_dynCall( { "AdsSetDateFormat", hDLL, HB_DYN_CALLCONV_STDCALL}, "DD/MM/YYYY" )

Teste de SQL com DBF

MensagemEnviado: 19 Jan 2020 10:28
por Marcos Kieron
Fica complicado para usar ADS, creio que é melhor passar direto para um SQL, compensa o esforço

Teste de SQL com DBF

MensagemEnviado: 19 Jan 2020 11:17
por asimoes
Usando Bind
        AbreCommand( @oCommand )
         
         cSql := "SELECT * FROM APA01 WHERE CODIGO = ?"
         
         WITH OBJECT oCommand
            oPrm := :CreateParameter("CODIGO", adVarChar, adParamInput, 5, "20735")
                    :Parameters:Append( oPrm )
                    :CommandText := cSQL
                    :CommandType := adCmdText
            oRs := :Execute()
         END
         
FUNCTION AbreCommand( oCommand )

   WITH OBJECT oCommand := Win_OleCreateObject( "ADODB.Command" )
      :ActiveConnection := oConexao
   END
   
RETURN Nil

Teste de SQL com DBF

MensagemEnviado: 19 Jan 2020 11:36
por asimoes
Marcos Kieron escreveu:Fica complicado para usar ADS, creio que é melhor passar direto para um SQL, compensa o esforço

Abra outro tópico e faça a sua sugestão, esse tópico é para quem quer testar o SQL com DBF, não significa que vai usar.

Teste de SQL com DBF

MensagemEnviado: 19 Jan 2020 12:41
por Marcos Kieron
?
Se está procurando um forum exclusivo, talvez vai ter que criar um só seu

Teste de SQL com DBF

MensagemEnviado: 19 Jan 2020 13:34
por Ranier
De novo aviso aos navegantes...
ADS é um produto comercial não livre, tem que comprar licença de uso.
https://www.sap.com/cmp/td/sap-advantage-database-server-trial.html
Quer usar um produto, realmente livre e não ter dor de cabeça, use PostgreSQL.

Muito informativo esse forum, muita propagada grátis de produto pago ou não passível de uso em produto comercial (GPL).

Teste de SQL com DBF

MensagemEnviado: 19 Jan 2020 13:43
por asimoes
Nem desenhando adianta, nego quer perturbar

Teste de SQL com DBF

MensagemEnviado: 19 Jan 2020 17:33
por asimoes
Se for usar o provider da Microsoft, atenção com campos tipo data, tem que usar # ou trabahar com bind
cSql := "SELECT * FROM ADMSAUDE WHERE DENTRADA BETWEEN #01/01/2018# and #31/12/2018# AND CODIGO = 'RIOP' ORDER BY DENTRADA"  // A DATA COM # PARA USAR COM OLEDB DA MICROSOFT

oConexao:ConnectionString := "Provider=Microsoft.Jet.OLEDB.4.0;Data Source=" + cPath + ";Extended Properties=dBASE IV;User ID=Admin;Password=;"

Teste de SQL com DBF

MensagemEnviado: 20 Jan 2020 02:36
por JoséQuintas
Ranier escreveu:De novo aviso aos navegantes...
ADS é um produto comercial não livre, tem que comprar licença de uso.
https://www.sap.com/cmp/td/sap-advantag ... trial.html
...
Muito informativo esse forum, muita propagada grátis de produto pago ou não passível de uso em produto comercial (GPL).


http://devzone.advantagedatabase.com/dz/webhelp/advantage9.1/advantage_local_server.htm

There is no cost for the Advantage Local Server. The Advantage Local Server is installed with all Advantage Windows and Linux client products (which are also free). This allows you to develop applications for single and multi-user environments and distribute them royalty-free when using the Advantage Local Server.
The Windows version of the Advantage Local Server is a DLL named ADSLOC32.DLL. The Linux version of the Advantage Local Server is a shared object named libadsloc.so.
...
If an Advantage application is distributed to work without the Advantage Database Server (i.e., it uses the Advantage Local Server to access data), the application must act as a "client" that directly accesses and uses the data. The application cannot act as "middleware" or as a "server" by having the data forwarded by any means to a separate computer. In other words, it is illegal to use the Advantage Local Server with a Web server, an application server, a terminal server, or any other type of middleware or server product to access data on behalf of remote computers. An Advantage Database Server (a.k.a., remote server) product must be purchased and used to allow an Advantage application to access data on behalf of applications running on remote computers.


NÃO TEM CUSTO.
Mas é proibido usar em um aplicativo que atue como servidor.

Como eu já disse em outro tópico:
O problema do mundo xbase é que todos querem vender algum produto.
E forçam para que os programadores não aprendam nada novo.

Aprender SQL encima de DBFs deixando mais rápido.... o que será das LIBs comerciais que trabalham com outras bases deixando igual DBF ??

Teste de SQL com DBF

MensagemEnviado: 20 Jan 2020 03:09
por JoséQuintas
E se alterar o aplicativo pra ADO, pra ADS com DBFs, e gostar....

Depois o programador vai ficar preso no ADO.... só tem 60 bases de dados na lista...

https://www.connectionstrings.com/

adi.png

Teste de SQL com DBF

MensagemEnviado: 21 Jan 2020 17:48
por asimoes
Eu estava me empolgando com ADS, então tentei usar:

oConexao:BeginTrans()

oConexao:CommitTrans()

oConexao:RollbackTrans()

Ai toiiiinn é DBF não adianta fazer um RollbackTrans, apesar de não dar erro, mas o registro é gravado. DBF não é um SGDB

Para usar até que vale por ser mais rápido e engrenar no SQL, depois é só migrar com poucas modificações.

Teste de SQL com DBF

MensagemEnviado: 21 Jan 2020 18:45
por Ranier
http://devzone.advantagedatabase.com/dz/webhelp/advantage9.1/advantage_local_server.htm

The Advantage Local Server allows both single-user and multiple-user access to data files. The Advantage Local Server file that is installed with Advantage client products contains a physical limitation such that only five or fewer users can concurrently access any table. This limitation was implemented to allow developers the ability to encourage their customers to upgrade to the Advantage Database Server client/server solution when more than five concurrent users were being used so as to reduce data corruption, increase application performance, and reduce support costs. If you wish to have more than five concurrent users accessing data via the Advantage Local Server, inquire about such support with your Advantage Sales representative or Advantage distributor.


Faltou dizer que essa "solução", é para uso somente com 5 usuários..., ou seja, vai nadar, nadar e morrer na praia.
Ficar perdendo tempo e dinheiro, muito melhor é partir pra uma solução definitiva, SQL com PostgreSQL.
Se vai acessar com ADO é outros 500, tanto faz, ninguém está impondo nada, estamos aqui esclarecendo somente.

"NÃO TEM CUSTO.", custo direto, talvez não, mas e os custos indiretos.

"Como eu já disse em outro tópico:
O problema do mundo xbase é que todos querem vender algum produto."

E você não? Ou você não tem produto comercial? Distribui de graça?
Pelo menos estou vendendo meu produto, e não o de outros, nem fazendo propaganda de produtos de terceiros.

"E forçam para que os programadores não aprendam nada novo."

Você é quem está forçando que outros aprendam, coisas inúteis, a longo prazo.

Aprender SQL encima de DBFs deixando mais rápido.... o que será das LIBs comerciais que trabalham com outras bases deixando igual DBF

Quem estiver usando a HBDBD, se sairá muito melhor, vejamos.
Poderá migrar para SQL, sem grandes transtornos, continuando a usar relatórios, browsers, com comandos xBase;
Poderá usar PostgreSQL, em Windows, Linux e FreeBSD;
Poderá usar Sqlite em Windows, Linux e FreeBSD.
Poderá usar MySQL em Windows, Linux e FreeBSD (legalmente), uma vez que a licença comercial, está na biblioteca.
Poderá usar REDIS cache em Windows, Linux e FreeBSD;
Poderá usar MongoDB (em desenvolvimento), com comandos MongoDB, diretamente do Harbour;
Enfim, a HBDBD, cria um novo patamar, único, avançado, não prendendo ninguém ao Windows, como a ADO faz hoje.

Mas, não estou "forçando" ninguém a comprá-la, use o que melhor convier.

Teste de SQL com DBF

MensagemEnviado: 21 Jan 2020 19:08
por JoséQuintas
Ranier escreveu:Faltou dizer que essa "solução", é para uso somente com 5 usuários..., ou seja, vai nadar, nadar e morrer na praia.


Que bom que quando usei não tinha isso.
Usei pra 20 usuários.
Se a limitação for do ODBC atual, só usar o anterior.

Estamos falando de usar em determinados relatórios, pra agilizar, NÃO será necessário pra inclusão/alteração/exclusão, apesar de poder usar, porque isso o Harbour já faz.

E o que tem a ver seu produto com isso?

Poderá usar MySQL em Windows, Linux e FreeBSD (legalmente), uma vez que a licença comercial, está na biblioteca.


Uia....
De repente o que era proibido virou permitido.

Ranier escreveu:como a ADO faz hoje.


ODBC tem no Linux, ADO é apenas uma das opções que não tem no Linux.

Primeiro o problema era o ADS, depois era o MySQL, agora é o ADO.....

Faltou você mencionar:

A Microsoft declarou que o ADO era obsoleto, isso foi logo que entrou o W7 SP1, alguns anos atrás.

É que no W7 SP1, ela alterou a comunicação pra 64 bits, e não liberou componentes pra Visual Basic 6.
Era alterou pra 64 bits, pra funcionar com o Office que ela havia lançado.
Ou seja, obsoleto para os outros mas não pra ela....
Na época, recomendou usar CreateObject() ao invés da forma original do VB6.

Bom... usa quem quiser.

Com certeza, até mesmo se for usar esse tal de HBDBD, não será nenhum problema se tiver treinado comandos SQL encima de DBF antes.

Teste de SQL com DBF

MensagemEnviado: 21 Jan 2020 19:17
por JoséQuintas
Arquivo de HELP distribuído com ADS Local

ADSLOCAL.png

Teste de SQL com DBF

MensagemEnviado: 21 Jan 2020 19:27
por JoséQuintas
Depois de 26 janelas desisti de tentar descobrir o limite...

ADSLOCAL.png

Teste de SQL com DBF

MensagemEnviado: 21 Jan 2020 19:44
por asimoes
Meu cliente são 4 máquinas, incluindo o servidor, então não tenho limitação.

Teste de SQL com DBF

MensagemEnviado: 21 Jan 2020 19:48
por JoséQuintas
Ia tentar estourar o limite usando multithread, mas ....
NÃO funciona com multithread.
Pelo menos aqui no teste, de jeito nenhum, mesmo reutilizando a mesma conexão já aberta, como faço no MySQL.

Teste de SQL com DBF

MensagemEnviado: 21 Jan 2020 22:17
por Ranier
JoséQuintas escreveu:Que bom que quando usei não tinha isso.
Usei pra 20 usuários.
Se a limitação for do ODBC atual, só usar o anterior.

" The Advantage Local Server file that is installed with Advantage client products contains a physical limitation such that only five or fewer users can concurrently access any table"
Se o próprio fabricante diz que têm limitação física de uso, é porquê ou ele não permite mais o uso, ou realmente têm problemas se usar com mais de 5 usuários.
ISSO QUEM DIZ não sou eu, é o fabricante.
O acesso local ao ADS por mil processos, em uma estação, não passa de um "chute", o limite deve estar na camada de rede.

JoséQuintas escreveu:
Ranier escreveu:Poderá usar MySQL em Windows, Linux e FreeBSD (legalmente), uma vez que a licença comercial, está na biblioteca.

Uia....De repente o que era proibido virou permitido.

E continua proibido. A HBDBD têm licença comercial da MySQL para uso, então o usuário da HBDBD, estará usando legalmente.

JoséQuintas escreveu:ODBC tem no Linux, ADO é apenas uma das opções que não tem no Linux.
Primeiro o problema era o ADS, depois era o MySQL, agora é o ADO.....

Todos essas "soluções" têm problemas.
ODBC têm no Linux, mas pra usar precisa de algo mais, não têm como usar ODBC diretamente.
ADO só existe no Windows e precisa do ODBC, que em todos os posts que já li nesse forum, indica o uso da ODBC da MySQL que têm licença GPL ou comercial.
Sem falar que ODBC é um intermediário, que traduz as chamadas, querendo ou não, é mais lento que o acesso nativo.

JoséQuintas escreveu:Faltou você mencionar:
A Microsoft declarou que o ADO era obsoleto, isso foi logo que entrou o W7 SP1, alguns anos atrás.
É que no W7 SP1, ela alterou a comunicação pra 64 bits, e não liberou componentes pra Visual Basic 6.
Era alterou pra 64 bits, pra funcionar com o Office que ela havia lançado.
Ou seja, obsoleto para os outros mas não pra ela....
Na época, recomendou usar CreateObject() ao invés da forma original do VB6.

Informação inútil.

JoséQuintas escreveu:Com certeza, até mesmo se for usar esse tal de HBDBD, não será nenhum problema se tiver treinado comandos SQL encima de DBF antes.

HBDBD, não usa DBF. Melhor fazer a transição direto pro SQL do SGDB a ser usado, por exemplo o PostgreSQL.
Com certeza, terá custos para se fazer as correções do SQL do ADS para o SQL do PostgreSQL, nunca são 100% compatíveis.

Teste de SQL com DBF

MensagemEnviado: 21 Jan 2020 23:29
por JoséQuintas
Ok, ok,
Se não servir ADS, tem mais opções da Microsoft.
EU TENHO LICENÇA, posso gerar qualquer porcaria de programa pra distribuir os ODBCs junto.

odbc.png

Teste de SQL com DBF

MensagemEnviado: 22 Jan 2020 00:06
por Ranier
JoséQuintas escreveu:Ok, ok,
Se não servir ADS, tem mais opções da Microsoft.
EU TENHO LICENÇA, posso gerar qualquer porcaria de programa pra distribuir os ODBCs junto.
odbc.png

Licença do Visual Basic 6, produto pago da Microsoft, não autoriza a distribuição do ODBC da MySQL, tampouco do ODBC da ADS.

E como você bem disse, usando esses ODBCs da Microsoft, só com porcaria mesmo.

Resumo, não serve pra mais ninguém.

Teste de SQL com DBF

MensagemEnviado: 22 Jan 2020 00:41
por JoséQuintas
Só serve pra comprovar o que venho dizendo dos produtos xbase.

Fico imaginando agora quantos iguais a esse não tem nos atrapalhado no desenvolvimento.
Tudo isso porque fez um acesso a banco de dados.
Juntem a isso os que fizeram LIBs e outras coisas mais.

E aguardem... isso é só o começo... a invasão começou no harbour-users e vai se expandir cada vez mais....

Não pode ADS porque precisa licença
Não pode MySQL porque precisa licença

Melhor HBDBD, que precisa licença, mas o produto é dele, e ele é quem vai ganhar dinheiro...

Put. que par...

Teste de SQL com DBF

MensagemEnviado: 22 Jan 2020 13:10
por JoséQuintas
https://searchitchannel.techtarget.com/feature/Using-MySQL-licensing-Open-source-license-vs-commercial-license

É proibido desenvolver um produto comercial, como um programa de contabilidade, voltado para o MySQL como banco de dados sem disponibilizar o código no sentido de código aberto. Se as limitações da GPL não forem aceitáveis ​​para você como desenvolvedor comercial, você poderá vender seu produto (programa) JUNTO COM UMA LICENÇA COMERCIAL DO MYSQL.


Ranier escreveu:A HBDBD têm licença comercial da MySQL para uso, então o usuário da HBDBD, estará usando legalmente.


Confirmado! programadores xbase costumam ser enganados.
Confirmado! os clientes dele usam MySQL sem licença.

E agora?
Será que ele vai comprar licença de MySQL para os clientes, ou pelo menos avisar os clientes?
Sugiro a quem comprou HBDBD, que EXIJA sua licença de MySQL, afinal ele garantiu que a licença vinha junto.
Aliás.. não apenas uma licença, várias, uma para cada um de seus clientes.

Teste de SQL com DBF

MensagemEnviado: 22 Jan 2020 13:31
por Ranier
JoséQuintas escreveu:https://searchitchannel.techtarget.com/feature/Using-MySQL-licensing-Open-source-license-vs-commercial-license

É proibido desenvolver um produto comercial, como um programa de contabilidade, voltado para o MySQL como banco de dados sem disponibilizar o código no sentido de código aberto. Se as limitações da GPL não forem aceitáveis ​​para você como desenvolvedor comercial, você poderá vender seu produto (programa) JUNTO COM UMA LICENÇA COMERCIAL DO MYSQL.


Ranier escreveu:A HBDBD têm licença comercial da MySQL para uso, então o usuário da HBDBD, estará usando legalmente.


Confirmado! programadores xbase costumam ser enganados.
Confirmado! os clientes dele usam MySQL sem licença.

E agora?
Será que ele vai comprar licença de MySQL para os clientes, ou pelo menos avisar os clientes?
Sugiro a quem comprou HBDBD, que EXIJA sua licença de MySQL, afinal ele garantiu que a licença vinha junto.
Aliás.. não apenas uma licença, várias, uma para cada um de seus clientes.

Acho que nossa colega têm toda razão, vc deve ser mesmo doente.
Acho que você nào sabe ler e fica valente atrás de um teclado.

Você não vende seu produto junto com o MySQL, para os seus clientes?
Então a mesma M**** que vc escreveu aqui pra mim serve PRA VOCÊ MESMO!!!

Ou o anafalbetismo o impede de ler a licença de uso dos produtos MySQL da Oracle.
Eu não distribuo servidores MySQL, nem os vendo.
A HBDBD têm licença comprada para uso como cliente do MySQL, então os usuários da HBDBD estão sim legalmente usando MySQL.

Ao contrário dos seus clientes, que podem exigir o código fonte da bosta do seu produto, porquê você está violando a GPL ao usar seu PRODUTO COMERCIAL com produto GPL da Oracle (MySQL) sem ter a devida licença.

Favor um favor pra você mesmo, vai se tratar.

Teste de SQL com DBF

MensagemEnviado: 22 Jan 2020 15:15
por JoséQuintas
Ranier escreveu:Ou o anafalbetismo o impede de ler a licença de uso dos produtos MySQL da Oracle.
Eu não distribuo servidores MySQL, nem os vendo.
A HBDBD têm licença comprada para uso como cliente do MySQL, então os usuários da HBDBD estão sim legalmente usando MySQL.
Ao contrário dos seus clientes, que podem exigir o código fonte da bosta do seu produto, porquê você está violando a GPL ao usar seu PRODUTO COMERCIAL com produto GPL da Oracle (MySQL) sem ter a devida licença.
Favor um favor pra você mesmo, vai se tratar.


Se você deseja usar esses drivers em aplicativos comerciais, a seguinte regra está em vigor: Se os programas clientes do MySQL acessarem um servidor licenciado pelo MySQL, essa licença será válida para as bibliotecas do cliente. Portanto, geralmente não é necessário obter licenças para o uso de bibliotecas clientes, porque as bibliotecas clientes são incluídas automaticamente na licença do servidor.


Antes de iniciar o tratamento....
Ensine pra nós: Como fez pra licença de APLICATIVO COMERCIAL valer pra um cliente de acesso? só pro seu é que tá valendo isso e pra nenhum outro !!!

Teste de SQL com DBF

MensagemEnviado: 22 Jan 2020 15:47
por JoséQuintas
Ranier escreveu:Favor um favor pra você mesmo, vai se tratar.


HBDBD não precisa licença de MySQL...

Se todo mundo usar HBDBD....
Ninguém nunca mais precisa comprar licença de MySQL !!!
Essa licença deve ter custado milhões !!!
Ele é praticamente dono do MySQL agora !!!

E eu é que preciso de tratamento.... kkkkkkkkkkkkkkkkkkkkkkkkkk

Teste de SQL com DBF

MensagemEnviado: 22 Jan 2020 17:20
por JoséQuintas
Mas agora vamos a algo útil:

Interessa para os usuários atuais e futuros de MySQL, saber o valor da licença de MySQL para aplicativo.
Uma vez que comprou, já sabe qual é o valor.
Quanto custa?
E como vincula isso ao aplicativo, uma vez que sempre vai ter futuras versões?

Teste de SQL com DBF

MensagemEnviado: 23 Jan 2020 08:28
por bencz
Segue as informações, José!

https://www.mysql.com/products/

Vale a pena ler isto aqui também: http://www.macoratti.net/msql_lc1.htm

Teste de SQL com DBF

MensagemEnviado: 23 Jan 2020 11:20
por Poka
Complicado heim!

Graças a Deus escolhi o Firebird.

Poka

Teste de SQL com DBF

MensagemEnviado: 23 Jan 2020 16:11
por JoséQuintas
mysql.png


Liguei na revenda Oracle do Brasil e confirmei:

Se o aplicativo for de uso interno da empresa, pode usar o MySQL Community Server e não precisa de licença.

Aplicativos vendidos, com lucro, nesse caso vão precisar de licença PARA CADA SERVIDOR, e o valor é 2.000 dólares POR ANO.

Além disso, existem os forks MariaDB e Percona Server.
Do mesmo jeito que temos Harbour 3.2, Harbour 3.4, etc, também existem esses forks do MySQL.
Esses dois forks são os principais, e podem ser usados gratuitamente.

Qual a diferença entre MySQL e os forks?
Sei lá... talvez nunca precisemos de nada avançado que faça diferença...

Convém destacar:
NÃO EXISTE LICENÇA PRA LIB E/OU DRIVER DE ACESSO A MYSQL.
A informação sobre usar HBDBD e não precisar de licença MySQL é totalmente falsa.

Teste de SQL com DBF

MensagemEnviado: 26 Jan 2020 09:32
por asimoes
Usando bind ? na query
A leitura de um DBF

        cSql := "SELECT APC.CODIGO, ADM.TIPO, ADM.DSAIDA, APC.CLASSE_PG, APC.UTI "
         cSql += "FROM APC01 APC "
         cSql += "INNER JOIN ADMSAUDE ADM ON ADM.MATRICULA = APC.CODIGO "
         cSql += "WHERE "
         cSql += "   ADM.TIPO IN ('T','D') AND "
         cSql += "   ADM.DSAIDA IS NULL AND "
         cSql += "   SubString(ADM.CODIGO,1,3) = ? AND "
         cSql += "   APC.UTI = ? AND "
         cSql += "   SubString(APC.CLASSE_PG,1,2) NOT IN ('06','08','10','11','12') AND "
         cSql += "   APC.D_FALECI IS NULL AND "
         cSql += "   APC.D_DESLIG IS NULL AND "
         cSql += "   APC.CODIGO NOT IN (SELECT APD48.CODIGO FROM APD48 APD48 WHERE APD48.CODIGO = APC.CODIGO AND APD48.T_GUIA = ? AND APD48.ANOMES = ? ) "
         cSql += "ORDER BY APC.CODIGO"
         
         IF oConexao:State != adStateOpen
            oConexao:Open()
         ENDIF
         
         WITH OBJECT oCommand
            //oPrm := :CreateParameter("DENTRADA", adDate, adParamInput, 8, CTOD('01/01/2018'))
            //        :Parameters:Append( oPrm )
            //oPrm := :CreateParameter("DENTRADA", adDate, adParamInput, 8, CTOD('31/12/2018'))
            //        :Parameters:Append( oPrm )
            oPrm := :CreateParameter("01", adVarChar, adParamInput, 4, 'UTI')
                    :Parameters:Append( oPrm )   
            oPrm := :CreateParameter("02", adVarChar, adParamInput, 1, 'S')
                    :Parameters:Append( oPrm ) 
            oPrm := :CreateParameter("03", adVarChar, adParamInput, 1, 'A')
                    :Parameters:Append( oPrm ) 
            oPrm := :CreateParameter("04", adVarChar, adParamInput, 4, '2002')
                    :Parameters:Append( oPrm ) 
                    :CommandText := cSql
                    :CommandType := adCmdText
            oRs := :Execute()
         END


Carregando o ResultSet para uma HashTable

         nCol := ( oRs:Fields:Count ) - 1

         hTable := {}
           
         oRs:MoveFirst()
         
         DO WHILE ! oRs:Eof
            hRecord := Nil
            hRecord := {=>}
            FOR i:=0 TO nCol
               hRecord[oRs:Fields( I ):Name] := oRs:Fields( i ):value
            NEXT
            aAdd( hTable, hRecord )
             oRs:MoveNext()
         ENDDO

Teste de SQL com DBF

MensagemEnviado: 14 Jul 2023 11:00
por Mario Mesquita
Bom dia, pessoal.

Vendo os debates sobre o ADS, gostaria de saber se alguém usa em cliente satisfatóriamente.

Estava fazendo meus estudos e seguindo a dica do Quintas de usa-lo para treinar mas me bateu que podia usa-lo em produção em algumas áreas críticas em programas onde a busca em DBFs são lentas causando algumas queixas de clientes.

Seria sensacional pois seria uma transição suave para algum SGDB, que convenhamos leva tempo até ser 100% efetivada.

E em alguns casos, até poderia ficar assim em algumas coisas de baixa demanda ou ficarem para a última fase de uma migração.

Desde já agradeço qualquer opinião de vcs.

Saudações,
Mario.

Teste de SQL com DBF

MensagemEnviado: 14 Jul 2023 12:36
por JoséQuintas
Muitos no harbour-users usam o ADS diretamente pelo Harbour, e com comandos SQL, sem nem mesmo passar pelo ADO.
Por outro lado, isso depende de preparar LIB pra isso, o que pode complicar pra começar testes.

Eu não tinha reclamação de ninguém, então fui pelo mais longo: fui convertendo um pouco de cada vez pra MySQL, SEMPRE EM USO, um pouco de cada vez, o aplicativo misturava DBF e MySQL, com limitações no começo.
Quem precisava aprender MySQL não era o aplicativo, era eu, então isso deu certo, fui aprendendo já colocando em prática.
Bastante tempo aplicado no começo de uso, pra evitar imprevistos futuros, confirmar codepage, numéricos, etc.

Mas o ADS vai ser válido, porque já pode começar tirando proveito justamente das consultas a várias tabelas de uma vez, que é onde mais vai tirar proveito de usar SQL.
E faz muita diferença de velocidade, porque o acesso do Harbour registro a registro é justamente a parte mais demorada.

Sinceramente, nem precisa opinião de ninguém
Mais simples
Crie uma rotina pra digitar comandos e trazer resultados, e faça testes variados de consulta pra ver velocidade.
Vá direto nesses casos mais críticos, e vai ter uma resposta rápida, sem nem mesmo mexer nos fontes do aplicativo.
Vai ser digitar um comando equivalente ao que está lento, e ver se fica mais rápido.
Se o resultado for bom, vai ter sua resposta.

Só pra lembrar:
ADO vai ser só uma comunicação intermediária, ele vai só enviar comandos pro ODBC e receber o resultado.
A rapidez não vai ser por usar ADO, vai ser por usar o ODBC.
Se depois usar outro conector, se ficar mais lento, aí a culpa vai ser da conversão do resultado.
Converter o resultado pra DBF não vale a pena. Os conectores do harbour NÃO convertem pra DBF, eles usam como se fosse DBF, isso é diferente de converter.

Teste de SQL com DBF

MensagemEnviado: 14 Jul 2023 16:29
por marco.prodata
É 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á.

Teste de SQL com DBF

MensagemEnviado: 14 Jul 2023 21:45
por JoséQuintas
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.

Teste de SQL com DBF

MensagemEnviado: 17 Jul 2023 10:02
por Mario Mesquita
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.

Teste de SQL com DBF

MensagemEnviado: 17 Jul 2023 12:52
por JoséQuintas
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.

Teste de SQL com DBF

MensagemEnviado: 17 Jul 2023 16:24
por marco.prodata
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.

Teste de SQL com DBF

MensagemEnviado: 18 Jul 2023 08:51
por Mario Mesquita
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.

Teste de SQL com DBF

MensagemEnviado: 21 Jul 2023 12:40
por JoséQuintas
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.