Basicamente é criar uma conexão com o banco de dados, configurar, e abrir.
oConexao := win_OleCreateObject( "ADODB.Connection" )
oConexao:ConnectionString := ""
... outras configurações
oConexao:Open()
E no final do programa fechar:
oConexao:Close()
Lógico... tem caso de conexão cair, principalmente se for internet, então uma classe pode usar a controlar tudo isso, ao invés de colocar em cada fonte.
O resto, de um modo geral, é comando SQL.
É o aplicativo enviando mensagem pro servidor, e o servidor respondendo.
Inclusão? é usando o comando SQL de incluir, passa lá o comando com os nomes dos campos e os valores
oConexao:Execute( "INSERT INTO CLIENTES ( NOME, ENDERECO ) VALUES ( 'nome do cara', 'endereco do cara' )" )
Exclusão? é usado o comando SQL pra excluir. passa lá o comando e o que quer excluir
oConexao:Execute( "DELETE FROM CLIENTES WHERE CODIGO = 10" )
Alteração? é usado o comando SQL pra atualizar e passa lá o que quer alterar
oConexao:Execute( "UPDATE CLIENTES SET NOME='novo nome' WHERE CODIGO = 10" )
E buscar informações, este talvez seja o ponto diferente entre usar ADO, SQLMIX, hbMySQL, etc.
oResultado := oConexao:Execute( "SELECT * FROM CLIENTES" )
Qual a diferença entre ADO, SQLMIX, hbMySQL neste ponto?
o ADO retorna no formato ADO, uma classe da Microsoft
o SQLMIX retorna no formato parecido com DBF - parece DBF mas não tem nada no disco (eu acho)
o hbMySQL retorna no formato Array
CADA um retorna em seu próprio formato, em cada um vai usar de um jeito diferente.
Isso não é visível para o programador, não é um arquivo físico, é apenas o modo de usar.
O formato do ADO é o chamado recordset.
Por isso, na maioria dos fontes, seja Visual Basic ou não, costumam usar Rs como variável
TANTO FAZ o nome, é uma variável.
oResultado := oConexao:Execute( "SELECT ..." )
Rs := oConexao:Execute( "SELECT ..." )
oConsulta := oConexao:Execute( "SELECT ..." )
oTemporario := oConexao:Execute( "SELECT ..." )
clientes := oConexao:Execute( "SELECT * FROM CLIENTES" )
O ponto chave nisso, é que não fica preso a usar um único arquivo, como no DBF.
Dá pra usar tudo, de tudo que é lugar, junto, misturado, tratado, filtrado, relacionado, somado, organizado....
A única coisa que o aplicativo precisa é essa conexão, pra trocar mensagens com o servidor.
Isso, por si só, já é uma grande diferença entre usar DBF.
Por isso não existe nada mágico que faça tudo automático.
Se fizer automático... vai estar usando SQL igual DBF, o que pode ficar um lixo.
O ponto que sempre chamei atenção sobre o ADO é que ele deixa bem claro qual é a diferença entre DBF e SQL.
Voltando ao recordset do ADO.
Ele tem a maioria das coisas que usamos no DBF, mas não com o mesmo nome:
ADO:Eof()
ADO:Bof()
ADO:RecordCount()
ADO:MoveFirst()
ADO:MoveNext()
ADO:MovePrevious()
ADO:Fields:Count()
E o campo pode ser acessado por número ou letra, sendo que o menor é ZERO e não 1.
ADO:Fields( "CODIGO" ):Value
ADO:Fields( 0 ):Value
ado:Fields( 10 ):Value
Juntando tudo isso, uma rotina pra listar ficaria assim:
oConsulta := oConexao:Execute( "SELECT * FROM CLIENTES ORDER BY NOME" )
DO WHILE ! oConsulta:Eof()
? oConsulta:Fields( "CODIGO" ):Value
? oConsulta:Fields( "NOME" ):Value
? oConsulta:Fields( "ENDERECO" ):Value
oConsulta:MoveNext()
ENDDO
oConsulta:Close()
É relativamente simples, é isso, e o resto, tudo tem a ver com comandos SQL, recursos do servidor SQL.
Lógico, até se acostumar, vai longe.
Exemplos:
- SQL não aceita data zerada/vazia " / / "
- SQL ACEITA NULO, digamos o NIL do Harbour
- SQL geralmente trata data como sendo campo datetime
- Se no SQL o campo é string com 30 posições, dá erro se tentar gravar com 40
- SQL aceita campo string VARIÁVEL, pode ter de 0 a infinitos caracteres
E por aí vai
Pode deixar compatível com DBF?
Até pode.... mas não compensa.
Fixar um texto com 80 posições, pra facilitar no programa, por exemplo.
De repente 1 milhão de registros com texto vazio ocupa nada, mas se fixar 80 posições, vai ocupar 80 milhões de caracteres.
E é justamente aí que entra o que falei, de usar uma classe.
Já pensou em todos os fontes, ficar tratando nulo, tamanho de string, etc. etc. etc. ?
Pois é.
E outra: e se você for fazer um programa pra uma base SQL que já existe?
Então... acaba sendo interessante trabalhar com o SQL no padrão dele, sem ficar configurando coisas diferentes.
Vai ficar preparado pra qualquer coisa que possa acontecer.
REFORÇANDO:
ADO é apenas um intermediário, que usa o formato ADO.
HBMYSQL é outro intermediário, que usa o formato Array
SQLMIX é outro intermediário, que usa o formato DBF.
O SQLMIX se divide, porque mesmo usando igual DBF, internamente ele pode se conectar com ODBC, por exemplo, que abre possibilidade pra outros bancos de dados, igual o ADO.
Qual deles é melhor?
O melhor é o servidor, e usar o servidor ao máximo, usando comandos SQL.
TODAS as opções permitem isso.
Por um lado, o ADO já te deixa visível exatamente do que se trata, isso pode ser bom pra aprender, mas talvez não pra usar.
Por outro lado, o SQLMIX te dá a oportunidade de usar mais rápido, facilitando boa parte da complicação que seria usar diretamente.
hbMySQL seria por array, vai de cada um ter dificuldade ou não com array
Qual deles é melhor?
Tem tanta coisa pra aprender sobre SQL, se ficar querendo decidir o que usar, só vai perder tempo.
Usa o que se sentir mais confortável e pronto.
O importante é começar a fazer testes, entender o funcionamento da troca de mensagens, entender a diferença entre DBF e servidor SQL.
O resto vém com o tempo.
NÃO é sair convertendo todo aplicativo.
É primeiro fazer testes, e ir se acostumando, ir se sentindo confortável.
Coloca alguma coisa simples pra teste, que o aplicativo possa funcionar com ou sem isso, e vai se aprofundando aos poucos, e tendo certeza que tudo está funcionando.
Só depois vai mais fundo.
O tempo vai dizer a hora certa... mas... lógico... você precisa dar um empurrãozinho pra esse tempo não virar uma eternidade.