Você está na página 1de 6

Métodos de Conexão

ADO (Access Data Object), DAO (Data Access Object). Drivers ODBC e Drivers OLE DB.

DAO (Data Access Object)

O DAO foi um dos primeiros métodos desenvolvidos para conexão dos


Sistemas Gerenciadores de Banco de Dados na plataforma baixa. Trata-se
de um método simples, um pouco ultrapassado porém ainda muito usado
por conexões internas de alguns núcleos básicos do Windows e de algumas
aplicações Microsoft como o Winamp.

A real vantagem do DAO é a quantidade de funções do método e a


simplicidade para criação do objeto de conexão, principalmente dentro do
código VBA. Como o método .SEEK. Que efetua a procura por um registro
de forma exata, diferente do FIND do ADO, agindo com a mesma precisão e
exatidão de uma instrução SQL. Todavia propicia um código um pouco
encardido, antigo e com funções incompletas, em especial no uso aplicado
no VB, para manutenção dos recordset's e isso se deve ao fato de que o
DAO não instancia Command's em memória como sua evolução, seu
sucessor, o ADO.

Exemplo de Conexão DAO:

Visual Basic

Dim DB As Database
Dim TBCliente As Recordset

Private Sub Form_Load()


Set DB = OpenDatabase("c:aulavbpedidos.mbd")
Set TBCliente = DB.OpenRecordset("TB Clientes", dbOpenTable)
Atualizar
desabilitar
End Sub

SubuHabilitar()
TxtCodigo.Enabled = True
TxtNome.Text = True
TxtEndereco.Text = True
TxtCidade.Text = True
TxtCep.Text = True
TxtDataCad.Text = True
TxtEstado.Text = True
TxtObservacao.Text = True
OptPreferencial.Enabled = True
End Sub

Sub Gravar()
TBCliente("CodigoCliente") = TxtCodigo.Enabled
TBCliente("nomecliente") = TxtNome.Text
TBCliente("enderecocli") = TxtEndereco.Text
TBCliente("cidadecli") = TxtCidade.Text
TBCliente("cepcli") = TxtCep.Text
TBCliente("datacadastro") = TxtDataCad.Text
TBCliente("estadocli") = TxtEstado.Text
TBCliente("observacaocli") = TxtObservacao.Text
TBCliente("preferencialcli") = OptPreferencial.Value
End Sub

Sub Desabilitar()
TxtCodigo.Enabled = False
TxtNome.Enabled = False
TxtEndereco.Enabled = False
TxtCidade.Enabled = False
TxtCep.Enabled = False
TxtDataCad.Enabled = False
TxtEstado.Enabled = False
TxtObservacao.Enabled = False
OptPreferencial.Enabled = False
End Sub

Sub Atualizar()
TxtCodigo.Text = TBCliente("CodigoCliente")
TxtNome.Text = TBCliente("nomecliente")
TxtEndereco.Text = TBCliente("enderecocli")
TxtCidade.Text = TBCliente("cidadecli")
TxtCep.Text = TBCliente("cepcli")
TxtDataCad.Text = TBCliente("datacadastro")
TxtEstado.Text = TBCliente("estadocli")
TxtObservacao.Text = TBCliente("observacaocli")
OptPreferencial.Value = TBCliente("preferencialcli")
End Sub

Sub Limpar()
TxtCodigo.Text = ""
TxtNome.Text = ""
TxtEndereco.Text = ""
TxtCidade.Text = ""
TxtCidade.Text = ""
TxtCep.Text = ""
TxtDataCad.Text = ""
TxtEstado.Text = ""
txtobservacxao.Text = ""
OptPreferencial.Value = False
CmdGravar.Enabled = False
CmdCancelar.Enabled = False
End Sub
Microsoft Access (VBA)
Option Compare Database
Option Explicit

Public Function ConectaBanco()

'Variáveis utilizadas
Dim objConn As Database
Dim rstRecorset As Recordset
Dim strSQL As String
Set objConn = CurrentDb()

'Foi feito uso de um nome de tabela qualquer


strSQL = "SELECT T_ConferirAtivarTDO.* FROM T_ConferirAtivarTDO;"
Set rstRecordset = objConn.OpenRecordset(strSQL, dbOpenDynaset)

End Function
A única maneira de se efetuar uma conexão usando o método DAO é
atráves do Interpretador e Gerenciador de drivers de acesso a dados do
Windows, o ODBC. Todas as conexões disparadas a partir deste método
passam pelo interpretador de comandos ODBC e este provém o acesso a
fonte de dados em uma espécie de sistema 03 camadas.
Quando o Visual Basic passou a ser o Front End a frente de grandes bancos
como o Oracle e até mesmo quando estes grandes bancos passaram a ter
um suporte multiusuário muito maior, gigantesco. A Microsoft passou a ter
problemas com sua fonte de dados ODBC. Foi um tal de corromper banco
.MDB, carregar DLL's em memória e logo em seguida com a destruição dos
objetos de conexão (Recordset's), devolve-las destruídas. Tentou-se
remodelar a fonte, mas nem todos os desenvolvedores sabem manejar
corretamente o ODBC e criar configurações avançadas e ou Data Sources
para vinculações especiais de Dados.
A fonte de dados parecia estar com os seus dias contatos pois o DAO a
degradava a cada dia. . .

ADO (Access Data Object)


As fichas de Bill Gates foram covardes. Em meados do término de 1996, o
mercado recebeu a primeira versão oficial do ADO, um novo método de
conexão cuja as principais promessas eram rapidez, destreza e total
eficiência no acesso.
A premissa principal era a que o ADO ignorava todos os núcleos da fonte de
dados ODBC, mas na prática sabemos que não é bem assim que se procede.
É possível efetuar conexão ADO via ODBC. Na verdade o ADO foi
desenvolvido junto a um pacote de Drivers de conexão chamados de Data
Access pré configurados e testados no ODBC. Eles ganharam o nome de
Drivers OLE DB, traduzindo temos algo como objetos pré configurados para
acesso ao banco de dados.
A conexão OLE DB é parcialmente moderna, exigindo os extremos da
máquina (Hardware). Porém é muito mais prático conectar-se via OLE DB do
que ODBC. Entretanto ainda é recomendável fazer um breve estudo antes
de sair optando por um ou por outro método de conexão, atente também a
possibilidade de fazer uso de outros métodos além do ADO e DAO. Pode-se
usar o RDO, o ODBC por meio de Componente Active X, ADO com Data
Enviroment como vimos em inúmeras matérias da Coluna VB, e outros.
Os driver's OLE DB são uma alternativa eficaz para desenvolvedores que
estão iniciando suas atividades no mundo descompassado da programação.
Você deve se lembrar bem ! Afinal, quem ainda não gerou um arquivo .UDL
(Microsoft Data Link). Estes arquivos formam uma rotina de conexão
completa para a base.

***
Não posso terminar a matéria, não me sentirei bem concluindo esta matéria
sem falar dos planos de acesso e de alguns drivers OLE DB onde o VB (Front
End), faz um pedido ou uma atualização ao banco, esse pedido é agendado
e disparado pelo método de conexão, como o ADO por exemplo. Sendo
assim, o acesso a base é feito a instrução é interpretada e caso o pedido
agendado seja disparado com instrução pura como o método Execute do
ADO, será tudo mais rápido note:
Set rsIbest2003 = cConn.Execute " SELECT NOMETABELA.CODIGO "
Se por você fez uso dos métodos do ADO, eles terão que ser decodificados
em instrução e em seguida tacados para dentro do Banco. Como a QBE
Gráfica (Query Basic Estrutuct) das Consultas do Access.Que retorna a
informação após traçar o plano de acesso do comando.
rsIbest2003 = cConn.OpenRecordset(NOMETABELA, OpenOptimist)
Um dos Driver's ODBC/OLE DB que eu posso com certeza largar o verbo e
encher a boca para falar é o Microsoft JET, ou Motor JET que todos já pelo ao
menos ouvimos falar. Ele é o driver responsavél pela conexão e
interpretação de comandos do Access.
A primeira questão que proponho é a seguinte: Porque a Microsoft criou o
JET?
Compatibilidade seria a resposta. O Microsoft Access foi projetado em cima
de um outro banco conhecido e que hoje virou apenas um simples
interpretador. O Fox Pro. O banco mais popular do mercado acompanhou em
parelelo a evolução do Fox Pro, evoluindo-se por conta deste. Todavia, os
empecilhos do mercado trouxeram a Fox Pro a falência e a completa
estagnação por parte dos grandes lobos milionários. Em suma, no final das
contas a Microsoft comprou a Fox Pro e o direito dos softwares. Comprou por
uma bagatela uma empresa mau humorada e repugnante sob o ponto de
vista profissional.
O balancete disto foi uma versão do Access 2.0 pré compilada com os
núcleos do Fox Pro. Um ambiente gráfico amigável e de fácil manejo aliado a
um poderoso banco flexível coordenados por uma mágica da equipe de Bill
Gates que sucumbiu uma dificuldade plena para interpretar as instruções do
banco Fox Pro. Como enviar dados de um software codificado em Visual
Basic com pouquissímas procedures em linguagem C como é o caso do
Access, para um software que nem mesmo eles sabiam operar totalmente;
diante de um prazo de entrega apertado e sem luxos maiores.
Para solucionar o problema criou-se o JET. O Motor de acesso para a base
Fox Pro, que futuramente se tornará um software independente no mercado.
Dynaset - O Sistema acessa determinados dados travando as tabela(s)
consultada(s). Permite alterar, incluir e deletar dados.
Snapshot - O Sistema cria uma imagem dos dados e libera as tabela(s)
consulta(s). Não permite alterar, incluir e ou deletar dados.
Quando realizamos uma consulta do Tipo Dynaset por Exemplo, o usuário
solicita os dados, o Access recebe os dados e efetua o pedido ao JET, que
independente do método usado (ADO, DAO, RDO) acessa a estrutura banco
Fox Pro, contido no arquivo .MDB, interpreta e traz em uma espécie de
pacote TCP/IP os dados para o ambiente gráfico de interação com usuário.
É importante ressaltar que não é o banco Fox Pro que está dentro do banco
.MDB do Access. Na verdade, a estrutura do banco .MDB foi projetada em
cima do antigo banco Fox Pro, pois o arquivo .MDB não se trava de um único
banco, existem inúmeras partições que propiciam ao usuário Access criar os
formulários, consultas, e até mesmo codificar montando uma aplicação
completa, que com o auxílio do pacote Develop Edition do Office
podemos até gerar um .EXE do arquivo .MDB desenvolvido.
Agora vocês conseguem entender o porquê que a Instrução SQL montada
pelo Access é tão repleta de parenteses e chaves diferente do que estamos
acostumados a aplicar no SQL Server e ORACLE, donos de driver's próprios
para conexão.

Você também pode gostar