Entendendo ADO/Cliente-servidor/SQL

[JoséQuintas]

Para os velhinhos que nem eu..... rs

Muitos aqui começaram usando o DBASE.
E devem se lembrar dos comandos que eram aceitos nele.

LIST FOR CLIENTE = 5
LIST DOCUMENTO, EMISSAO, VENCIMENTO, VALOR FOR CLIENTE = 5
SET RELATION TO CLIENTES INTO CODCLI
LIST DOCUMENTO, EMISSAO, VENCIMENTO, VALOR, CLIENTES->NOME FOR VALOR > 100

Pois é...
O SQL é como se voltasse esse tempo do DBASE.
Só que ao invés de digitar o comando, o computador é que envia o comando pro servidor, e o servidor responde.

É como se o computador digitasse esse LIST, e o servidor retornasse o resultado da consulta.

Em DBASE:

USE FINANCEIRO
LIST DOCUMENTO, EMISSAO, VENCIMENTO, VALOR FOR CLIENTE =5
E o resultado aparece na tela

Em MYSQL

SELECT DOCUMENTO, EMISSAO, VENCIMENTO, VALOR FROM FINANCEIRO WHERE CLIENTE = 5
E o resultado vém no formato da LIB usada, que pode ser recordset no ADO, array na classe TMySQL, DBF na SQLMIX, etc.
Basta usar o resultado da consulta.

E os tais geradores de relatório?
Voltemos ao DBASE:

USE ARQUIVO
REPORT FORM arquivo.frm FOR CLIENTE=5 TO PRINT

O grande sucesso do DBASE foi a facilidade de obter dados via comandos.
O SQL é exatamente a mesma coisa, mas que o aplicativo também pode usar.

O DBASE morreu?
Dependendo do ponto de vista.... talvez ele tenha evoluído para o SQL.

Então temos:
- O SQL, que seria o estilo de comandos interativos do DBASE, mas com uso mais universal, e mais poderoso
- O formato de gravação... aí inventaram vários: MySQL, SQL Server, Firebird, etc... que usam os comandos SQL padronizados. Para o programador, nem faz diferença esse "formato binário", já que os comandos SQL fazem tudo que precisa, e retornam as informações do jeito que precisa
- A linguagem de programação... se o banco de dados pode fazer muita coisa... a linguagem de programação passa a ser gosto pessoal, nem importa muito, porque ela vai só enviar comandos e receber respostas.

Quantas vezes você já não pensou isto:
"É tão fácil no DBASE digitar comandos pra buscar coisas.... e no aplicativo é complicado...."

Pois é... o SQL resolveu essa questão.
Pode fazer muitos browses/grids no aplicativo, gerados a partir de comandos SQL.

Precisa de uma tela pra listar pedidos pendentes......
Pense no DBASE... como faria isso com o comando LIST.... é só fazer o mesmo, mas com o comando equivalente SELECT.

SELECT * FROM PEDIDOS WHERE STATUS="PENDENTE"
Só isso e o browse/grid e tá pronto.

E totalizado? tinha isso no DBASE também:
USE PEDIDOS
LIST SUM( VALOR ) FOR CLIENTE = 5

Em SQL, juntou tudo numa linha só:
SELECT SUM(VALOR) FROM PEDIDOS WHERE CLIENTE = 5

"Talvez" pensar no SQL como o interativo do DBASE ajude a entender melhor o que é o SQL.
A diferença é que você não digita, você envia o comando pelo aplicativo, e quem faz o trabalho não é o computador do aplicativo e sim o servidor que seria o "dbase".

[lugab]

Obrigado, mestre.
Agora sim, eu vou aprendee essa bagaça...

[JoséQuintas]

Pois é... de vez em quando vém a inspiração...

Vamos lá... um exemplo de ADO:

Código: Selecionar todos

LOCAL cComando := Space(250), cnMySql, Rs

cnMySql := ConexaoMySql() // sem detalhes, não vém ao caso do exemplo
cnMySql:Open()
DO WHILE .T.
   @ 2, 10 GET cComando PICTURE "@KS 80"
   READ
   Rs := cnMySql:Execute( cComando )
  IF "SELECT" $ cComando
      // Browse do resultado, ou relatório, ou outra coisa
       Rs:Close()
   ENDIF
ENDDO
cnMySql:Close()

Basicamente o uso vai ser esse.

Lembram?
Igual digitar no dbase, mas é o aplicativo enviando as mensagens.
Ou igual mensagens do WhatsApp.

Junto ao aplicativo não existem arquivos, não existem DBFs....
O aplicativo apenas fica enviando mensagens para o servidor.

Criar banco, criar tabela, incluir, excluir, pegar informações...
O aplicativo manda mensagem e o servidor executa, podendo ou não enviar resposta.

Se o comando for pra pegar informações... o servidor manda a resposta em formato.... nesse caso no formato ADO.

A coisa é simples assim, só complica porque ficamos pensando em DBF, e não nessa troca de mensagens.

Quer a lista de clientes.
Em dbase digita lá: USE CLIENTES; LIST

Em ADO/SQL, no programa acima vai digitar: SELECT * FROM CLIENTES
E o retorno vai ser o "temporário" no formato ADO.

Código: Selecionar todos

temporario := cnMySql:Execute( "SELECT * FROM CLIENTES" )
DO WHILE ! temporário:Eof()
   ? temporário:Fields( 0 ):Value
   ? temporário:Fields( 1 ):Value
   temporário:MoveNext()
ENDDO
temporário:Close()

Vamos comparar com DBF:
Pra pegar o conteúdo de um campo podemos usar FieldGet() - até o nome é parecido

Código: Selecionar todos

USE arquivo
DO WHILE ! Eof()
   ? FieldGet( 1 )
   ? FieldGet( 2 )
   SKIP
ENDDO
CLOSE

ADO/SQL é isso e nada mais.
Ou envia um comando pra incluir, alterar, excluir, etc.
Ou envia um comando que retorna informações, e basta trabalhar com elas.

Complicado?
O funcionamento é simples.
O que torna complicado é que estamos acostumados com DBF, e trocar mensagens não tem nada a ver com DBF.
É mandar mensagem certa, pra ter resposta certa.

Só o ADO é assim?
Não, SQL é assim.
E porque tantas LIBs diferentes pra acessar o banco SQL?
Porque cada LIB tenta facilitar de um jeito, algumas tentam imitar o DBF.

Diferenças práticas com relação do DBF:

Imaginem o browse do DBF....
Você está passeando no arquivo, se alguém incluir alguma coisa, vai acabar aparecendo no seu browse.
No ADO/MySQL NÃO.
Porque?
Você enviou a mensagem, pediu a lista, a lista veio... FIM
Se está fazendo o browse, é referente a essa consulta.
Pra aparecer o que foi incluído depois, só mandando outra mensagem pedindo tudo de novo.

Está correto? sim

Imagine consultar os dados de um cliente. consultou, mostrou na tela.
Se outro usuário fizer alteração... isso não vai alterar a sua tela, só se você consultar o cliente de novo.
Então.... é normal não atualizar o que está na tela.

São essas diferenças que temos que acostumar.

E aquelas LIBs, igual RDDSQL, que deixa usar SQL igual DBF?
Será que deixa mesmo? e se deixa, será que é vantagem? será que consegue mesmo fazer igual?
Será que não está toda hora consultando o servidor, pra poder manter a informação atualizada?
Pode ser a diferença entre ter um aplicativo ultra-rápido, ou um aplicativo lento, talvez até pior que DBF.

Pense nisso quando quiser usar SQL-cliente/servidor.
Se precisa algo rápido, pra não mexer muito em fontes, pode aproveitar todo fonte existente usando alguma LIB.
Mas com certeza isso não vai ser a solução definitiva.
Vai fazer ajustes depois, pra encontrar algum ponto de equilíbrio entre usar igual DBF ou usar como SQL mesmo.

O que é melhor fazer?
Vai de cada um, e de cada situação.
Se precisa usar SQL pra ontem... uma LIB pronta é a melhor solução.

Se não tem pressa... ou ainda não precisa... vai fazendo testes e se acostumando com essa nova idéia, esse jeito "diferente" de trabalhar.

Apenas pra refletir:
No final, o SQL que é diferente ou é o DBF que é diferente?