Esta é a segunda parte da série de artigos que compõem o curso online grátis de modelagem de dados no Microsoft Access 2003. Não deixe de ler a primeira parte do curso para acompanhar melhor as questões debatidas sobre o Microsoft Access e outros aplicativos do Microsoft Office tais como Microsoft Excell e Microsoft Word. Nesta continuação você aprenderá sobre RDBMS.



Que tipo de banco de dados é o Access e o que significa RDBMS?

O Access é um banco de dados relacional. Se você nunca ouviu falar em banco de dados relacional esta é uma ótima oportunidade para compreender o que isso significa.

A sigla RDBMS refere-se ao termo em inglês Relational Database Management System (Sistema de Gerenciamento por Banco de Dados Relacional). E o que isso significa? Colocando o preto no branco, isso quer dizer que os dados contidos no banco de dados possuem algum tipo de relação, isto é, o seu tio está relacionado a você porque ou ele é irmão de sua mãe ou de seu pai. Se não fosse, ele não teria nenhuma relação direta com você.

Um banco de dados relacional funciona assim. A tabela contendo todas as cidades brasileiras e do mundo pode estar relacionada com uma tabela contendo todos os países do mundo. Porém, somente o país Brasil está diretamente relacionado a todas as cidades brasileiras na tabela de cidades do mundo. Desta forma, se você tivesse que consultar o banco de dados por país para criar uma lista de cidades, ao escolher Brasil, somente as cidades relacionadas ao Brasil seriam listadas.

Agora, volte ao exemplo do seu tio. Eu disse que se ele não for irmão de seu pai ou mãe; então, ele não está relacionado a você diretamente. Mas isso não quer dizer que esta pessoa não esteja relacionada a você de alguma outra forma.

Se o mundo animal surgiu de apenas uma célula que gerou toda a vida no planeta Terra; então, todos os animais estão relacionados de uma forma ou de outra. Assim, os animais próximos têm um relacionamento direto, como leões e leoas, ao passo homem e leão não possuem relacionamento direto, mas ambos são seres vivos que possuem características simulares como sangue, cérebro, coração, fígado, etc, gerando assim uma relação indireta.

Em um banco de dados relacional, o que você notará é exatamente isso. Às vezes, você possui várias tabelas onde duas estão diretamente relacionadas, mas na ponta de uma cadeia de relacionamento há uma tabela que não contém um campo comum com uma tabela na outra ponta do relacionamento; porém, ambas as tabelas possuem algum relacionamento, pois no meio do caminho existem outras tabelas relacionadas que eventualmente convergem para estas duas. Obviamente que este é apenas um exemplo simples. O Access nos permite criar bancos de dados relacionais muito mais complexos do que isso..

Nesta série de artigos, falarei sobre a modelagem de dados no Microsoft Access 2003. Não obstante, você poderá utilizar os conceitos aqui descritos em outras versões do aplicativo, sejam elas mais antigas ou mais recentes. Dentre todos os aplicativos do Microsoft Office, certamente o Microsoft Excel é o mais popular entre os usuários, mas provavelmente o mais utilizado seja realmente o Word.



Talvez pela extrema popularidade entre os usuários, muitos acabam utilizando o Excel como uma base de dados para os mais diferentes tipos de trabalho. O problema em utilizar o Excel é que sua função principal é a análise de dados e não o armazenamento dos mesmos.

Não por acaso a Microsoft chama o MS Office como uma “suíte” de produtividade. A produtividade não está em um aplicativo apenas, mas na integração dos aplicativos para fazer o seu trabalho melhor. Suponha que você colete dados sobre a umidade relativa do ar a cada minuto. Se você tentar gravar estes dados no Excel 2003 não há problema algum, pois você fará 1440 medições no dia e o número máximo de linhas em uma única planilha é de 65.536.

Contudo, você provavelmente estará registrando a umidade para outras cidades também e certamente o fará todos os dias se este for o seu trabalho. Aqui, você começa a enfrentar problemas no Excel, pois ficará mais difícil manter a integridade e relacionamento dos dados.

Você pode argumentar que cada planilha leva o nome da cidade e que, portanto, esta é uma forma de relacionar as medições com cada cidade. Como o Excel, teoricamente, não tem limite de planilhas, você poderia gravar a medição para todas as cidades brasileiras, e até do mundo, utilizando este método.

Contudo o resultado é completamente ineficiente por um simples motivo: o Excel não foi feito para armazenar dados, o Excel foi feito para analisar dado. Se você compreender que no Access o mesmo armazenamento apenas necessita de duas tabelas (uma que contém as cidades e outra que contém as medições) você verá que a sua produtividade aumentará em muito, basta apenas relacionar as duas tabelas. Quando o momento for oportuno e a necessidade de análise de dados surgir, você novamente verá que analisar dados no Access, embora possível, é ineficiente. Com as ferramentas do Office completamente entrelaçadas você verá que a análise se dará de forma mais bela no Excel. E se você necessita apresentar os resultados, entra em cena o PowerPoint e se há necessidade de escrever um relatório é a vez do Word.

Quanto mais você se aprofundar no Office e conhecer cada uma de suas ferramentas, mais produtivo você se tornará. E digo isso por experiência própria.

Até a segunda parte deste curso...

CURSO ADO e ADOX COMPLETO

Caso você ainda não tenha lido a quarta parte, você pode acessá-la em ADO ADOX (ActiveX Data Objects).

2.7.     Tratamento de Erros

Dada a natureza estrita de um banco de dados será impossível ter um código infalível, portanto, é importante que o leitor saiba tratar os erros que possam aparecer para que possíveis problemas sejam resolvidos.

No código anterior possuo um tratamento de erro, embora não o use em todos os exemplos deste curso para não ser pedante com cada código escrito.

Geralmente utilizamos as seguintes instruções para lidar com os erros:

·         On Error GoTo “Rótulo”

·         On Error Resume Next

No primeiro caso, quando o erro ocorre o código é remitido para um rótulo dentro da rotina, por exemplo:

Sub RecordsetLike(ByVal strBusca As String, ByVal Tipo As String)

    On Error GoTo Err_Handler

'   Código a ser executado entra aqui

    Exit Sub

Err_Handler:

    MsgBox Err.Description, vbCritical, Err.Number

    Resume Limpar

End Sub

Note que antes do rótulo há a instrução Exit Sub. Esta instrução se faz necessária para evitar a execução do código logo abaixo do rótulo. Esta parte somente é executada quando há um erro.

O leitor pode ou não definir uma mensagem personalizada, mas se o erro é imprevisível o melhor e deixar em aberto a questão e passar a descrição do erro e o número do erro como é feito no exemplo acima.

Uma outra forma de tratar o erro é utilizar a segunda instrução conforme abaixo:

Sub RecordsetLike(ByVal strBusca As String, ByVal Tipo As String)

    On Error GoTo Err_Handler

'   Código a ser executado entra aqui

Limpar:

    On Error Resume Next

    rs.Close

    Set rs = Nothing

    Exit Sub

Err_Handler:

    MsgBox Err.Description, vbCritical, Err.Number

    Err.Clear

    Resume Limpar

End Sub

On Error Resume Next instrui o VBA a continuar a operação em caso de erro. O leitor precisa notar duas coisas aqui:

1.Adição da linha Err.Clear à Adiciono esta linha para limpar o erro causado antes do rótulo Limpar. O motivo para isso é que acima nós resumiremos o código neste ponto após o primeiro erro porém...

2.... Ao resumir no rótulo Limpar caso o primeiro erro tenha sido na abertura do recordset nós não teremos nenhum recordset para fechar o que causaria novo erro (conforme figura abaixo). Então, nós limpamos o erro antes de seguirmos para o rótulo Limpar e ali instruímos o código a continuar em caso de novo erro. Se não fizermos isso, entramos em um loop eterno na primeira instrução On Error GoTo:

Figura 2‑5 Erro retornado ao tentar fechar recordset que ainda não foi aberto

Obviamente que apenas passar a mensagem ao usuário não resolve o seu caso, pois você deseja saber o que está ocorrendo e caso o problema seja no código, você quererá corrigi-lo para evitar recorrência dos problemas.

Como estamos lidando com um banco de dados, talvez a melhor forma de fazermos isso seja através de uma tabela onde “logamos” os erros os quais são futuramente analisados e caso sejam problemas no código os mesmos sejam retificados.

CURSO ADO e ADOX COMPLETO

Caso você ainda não tenha lido a segunda parte, voce pode acessá-la em ADO ADOX (ActiveX Data Objects).

2.2 Abrindo, fechando e limpando um recordset

Antes de abrir um recordset é necessário a abertura de uma conexão, a menos que você queira utilizar um recordset desconectado (veja mais adiante como proceder).

Recordset está vinculado à base de dados e por este motivo precisamos da conexão aberta antes de proceder, sem isso a abertura de um recordset falhará.

Assim como a conexão, nós utilizamos o método Open para abrir o recordset e o método Close para fechá-lo.

Vejamos então um exemplo simples de como proceder:

Sub exRecordset ()

    Dim cn      As New ADODB.Connection

    Dim rs      As New ADODB.Recordset

    Dim strCn   As String

    strCn = "Provider=Microsoft.Jet.OLEDB.4.0;User ID=Admin;"

    strCn = strCn & "Data Source=C:\Northwind.mdb;"

    cn.Open strCn

    rs.Open "SELECT * FROM Categorias", cn, adOpenKeyset, adLockPessimistic

    Debug.Print rs.Fields.Count

    rs.Close

    cn.Close

    Set rs = Nothing

    Set cn = Nothing

End Sub

Quando iniciamos o processo de abertura de um recordset nós precisamos determinar alguns argumentos utilizados pelo método Open conforme mostra a figura abaixo:

Figura 2‑1 Argumentos do métodos Open

·         Source à Refere-se à fonte de dados para o recordset. Para ser mais específico, Source refere-se a uma instrução SQL a qual retornará os registros que desejamos. No exemplo acima, a instrução é de seleção (SELECT) de todos os registro (*) da tabela Categorias. A complexidade da instrução dependerá do tipo recordset que você deseja;

·         ActiveConnection à Refere-se à conexão que utilizaremos para retornar os dados;

·         CursorType à Refere-se ao tipo de cursor utilizado. O cursor determina como podemos movimentar dentro dos registro. Por exemplo, o cursor adOpenForwardOnly somente permite movimento para frente dentro do recordset o que implica que não podemos utilizar o método MovePrevious do recordset para mover para o registro anterior ao atual na ausência de um lock, pois neste contexto não é permitido;

·         LockType à Refere-se ao travamento dos registros para edição. Imagine o cenário onde um usuário acessa um registro agora para edição e outro acessa os mesmos dados dois segundos depois, o que ocorreria? Sem o devido travamento edições feitas por um usuário podem ser sobrescritas por outro. Para evitar isso, travamos os registros. adLockPessimistic pode ser usado para evitar acesso/edição simultânea ao passo que adLockOptimistic permitiria acesso e que um registro seja editado e salvo dependendo de qual usuário chama primeiro a execução do comando.

É basicamente isso que o leitor precisa saber para abrir um recordset. A maior dificuldade é realmente construir a instrução SQL que executará o que desejamos. Veja apêndice para maiores informações.

2.3 Abrindo, fechando e limpando um recordset desconectado (disconnected recordset)

No exemplo anterior vimos como abrir um recordset conectado, isto é, ele está conectado à base de dados sem a qual ele não existe. Por outro lado, um recordset desconectado implica que o mesmo não depende de uma conexão para existir.

Recordset desconectado serve uma função similar a uma matriz. Por exemplo, poderíamos ter a seguinte matriz

Matriz(0) = 0

Matriz(1) = 1

Matriz(2) = 3

Enquanto que não há nada de errado em criar uma matriz, até porque nós podemos redimensioná-la e preservar os itens existentes, um recordset desconectado pode nos servir bem para tal cenário, pois podemos adicionar campos a ele e depois apenas adicionamos os dados que desejamos (os quais podem vir de uma fonte conectada).

Vejamos como isso é feito:

Sub exRecordsetDesconectado()

    Dim rs      As New ADODB.Recordset

    With rs.Fields

        .Append "ID", adInteger

        .Append "Nome", adVarChar, 55

        .Append "Endereço", adVarChar, 255

        .Refresh

    End With

    With rs

        .Open

        .AddNew

            !ID = 100

            !Nome = "Robert Friedrick Martim"

            !Endereço = "Qualquer lugar"

        .Update

    End With

    Debug.Print rs.Fields(1).Name

    Debug.Print rs.Fields(1).Value

    rs.Close

    Set rs = Nothing

End Sub

O leitor provavelmente está se perguntando para que serve isso. Suponha que você deseja abrir um recordset, porém, como já sabemos, o mesmo estará conectado a base de dados o que nos causa um pequeno problema.

Uma solução seria declarar um recordset na área de declarações globais (no topo de tudo na janela do VBE) e armazenar os dados de um recordset conectado neste recordset global desconectado. Como ele não será destruído enquanto não for explicitamente feito, podemos utilizá-lo para trabalhar os dados sem a necessidade de solicitá-los várias vezes à fonte de dados.

Alternativamente, podemos utilizar o recordset desconectado para simplesmente armazenar uma matriz muito grande a qual não sabemos o limite superior de antemão, mas sabemos o número de colunas o que evitaria redimensionamento desnecessário de matriz (além da necessidade de preservar informações já contidas nela como um Redim Preserve).

2.4 Navegação de um recordset

No tópico sobre abertura de um recordset vimos brevemente o tipo de cursor que podemos utilizar nele. Agora, veremos como estes cursores afetam a navegação pelos registros.

Navegar pelo registros é bastante simples e precisamos apenas observar o tipo de cursor que desejamos utilizar e sua combinação com o tipo de lock do banco de dados para evitar erros.

Vejamos um exemplo:

Sub exNavegacao()

    Dim cn      As New ADODB.Connection

    Dim rs      As New ADODB.Recordset

    cn.Open strCn

    With rs

        .Open "SELECT * FROM Categorias", cn, adOpenKeyset, adLockOptimistic

        .MoveFirst

        Do While Not .EOF

            Debug.Print !NomeDaCategoria

            .MoveNext

        Loop

        Debug.Print vbCr

        .MovePrevious

        Do Until .BOF

            Debug.Print !NomeDaCategoria

            .MovePrevious

        Loop

    End With

    rs.Close

    cn.Close

    Set rs = Nothing

    Set cn = Nothing

End Sub

No exemplo acima listamos as categorias do início ao fim e depois do fim até o início. Os métodos utilizados na navegação são:

·         MoveFirst à Move o cursor para o primeiro registro do recordset;

·         MoveNext à Move o cursor para o próximo registro do recordset dado o registro atual;

·         MovePrevious à Move o cursor para o registro anterior do recordset dado o registro atual;

Poderíamos também utilizar MoveLast o qual teria o efeito oposto do método MoveFirst.

Caso o leitor tente utilizar adOpenForwardOnly sem um lock apropriado um erro ocorrerá conforme já explicado:

Figura

Neste tópico veremos alguns dos objetos importantes do ADO tais como “Connection” e “Recordset” assim como propriedades e métodos destes objetos os quais utilizamos para efetuar tarefas em nosso banco de dados. Você pode checar o primeiro artigo sobre ADO ADOX (ActiveX Data Objects).

Inicio pela conexão, pois nós precisamos de uma conexão aberta para abrir conjuntos de registros (recordsets) e efetuar operações em registros e tabelas como inserção, exclusão e edição de registros.

Vejamos então como abrir uma conexão em ADO.

Via de regra, para abrir um conexão ADO nós utilizamos o método Open de um objeto Connection. A parte importante aqui é a string de conexão. Conforme já explicado, podemos obter tal string diretamente do banco de dados através da propriedade Connection do objeto CurrentProject. Feito isso, basta copiar a string para utilização no seu projeto Excel.

Uma outra alternativa é utilizar um Data Link. Data Link será discutido mais adiante no curso.

Se a fonte de dados muda, então uma string é mais apropriada, pois não está ligada a uma fonte específica, bastando apenas adaptar conforme necessário (ou criar uma função para retornar a string dado certos parâmetros). De qualquer modo, a decisão final ficará a cargo mesmo de quem programa.

Para abrir a conexão podemos utilizar o seguinte código:

Sub conexao()

    Dim cn      As ADODB.Connection

    Dim strCn   As String

    strCn = "Provider=Microsoft.Jet.OLEDB.4.0;User ID=Admin;"

    strCn = strCn & "Data Source=C:\Northwind.mdb;"

    Set cn = New ADODB.Connection

    cn.Open strCn

End Sub

Note que acima, primeiramente declaramos o objeto, em seguida o instanciamos e finalmente o abrimos utilizando o método Open  do objeto Connection para abrir a conexão. Uma alternativa a isso é simplesmente declarar e instanciar ao meu tempo e logo a seguir abrir a conexão:

Sub conexao()

    Dim cn      As New ADODB.Connection

    Dim strCn   As String

    strCn = "Provider=Microsoft.Jet.OLEDB.4.0;User ID=Admin;"

    strCn = strCn & "Data Source=C:\Northwind.mdb;"

    cn.Open strCn

End Sub

Uma vez que a conexão esteja aberta e tenhamos terminado o seu uso, nós precisamos fazer duas coisas com ela:

1.Fechá-la

2.Limpá-la da memória

Para fechar uma conexão nós utilizamos o método Close do objeto. Para limpar o objeto da memória nós o setamos como sendo Nothing (nada):

cn.Close

Set cn = Nothing

Portanto, o processo completo entre declaração, abertura, fechamento e limpeza da conexão ficará:

Sub conexao()

    Dim cn      As New ADODB.Connection

    cn.Open strCn

'   Executaremos algo neste espaço

    cn.Close

    Set cn = Nothing

End Sub

Agora que o leitor já sabe como efetuar os passos acima, vejamos como abrir um recordset (conjunto de registros) o qual depende de uma conexão aberta para ser viável.

Bem-vindo ao Curso Excel 2003 online totalmente grátis sobre o ADO (ActiveX Data Objects) e ADOX. Com esta séria você poderá montar a sua apostila de Excel 2003 sobre ADO/ADOX. Caso o leitor não queira imprimir o material, objetivando a economia de papel, o meio ambiente agradecerá a grande ajuda.

Um ponto importante sobre este curso é que ele não virá com as planilhas Excel prontas. O leitor terá que construir as planilhas a partir do curso. Caso o leitor queira, ele pode obter o curso completo de ADO e ADOX (ActiveX Data Objects) em nossa loja.

Focando em nosso curso, se alguma vez o leitor programou acesso de dados no Access a partir do Excel você certamente já utilizou a biblioteca do Data Access Objects (DAO) ou do ActiveX Data Objects (ADO). Aqui, irei discutir somente o ADO e o DAO ficará para um módulo em separado (veja no site como obter o outro módulo  sobre DAO) para que os conceitos sejam compreendidos separadamente.

O usuário comum do Access provavelmente não se interessará pela utilização de VBA para efetuar o seu trabalho. Contudo, se o seu trabalho envolve o desenvolvimento de bancos de dados, então, conhecer o VBA e os métodos de acesso e manipulação de dados será crucial.

Como toda e qualquer biblioteca, a biblioteca ADO possui uma hierarquia. Dentro desta hierarquia existem objetos que são, de modo geral, mais importantes que outros.

A biblioteca ADO, assim como qualquer outra biblioteca, contém um conjunto de objetos que pertence a um mesmo grupo. Desta forma, fica relativamente fácil encontrar um objeto dentro de um grupo e, consequentemente, isolar as propriedades e métodos de tal objeto[1].

No decorrer deste módulo irei apresentar cada um deles individualmente com exemplos de como utilizá-los.

ADO pode ser utilizado para um número extenso de tarefas. Olharemos tais tarefas no decorrer do curso e como as mesmas podem nos ser úteis.

1.1.     Um pouco da história do ADO

A grande vantagem da utilização de DAO sobre ADO é que DAO é especificamente designado para os Jet Databases. Não obstante, como DAO funciona em cima do Jet Database Engine quando o assunto é conexão remota ADO superado DAO.

Muitos websites, mesmo utilizando um banco de dados Access, por exemplo, tendem a utilizar ADO na conexão de dados em detrimento ao DAO, pois ADO foi desenvolvido com a principal intenção de se conectar com as mais variadas fontes de dados.

ADO faz parte do esforço da Microsoft para criar uma biblioteca universal de acesso de dados (chamada de UDA – Universal Data Access).

1.2.     “Strings” de conexão

O provedor para uma conexão ADO é o Microsoft. Jet.OLEDB.4.0. Como a conexão em si possui vários parâmetros o leitor deve estar se questionando como lembrar isso tudo de cor. A verdade é que não precisamos.

Quando chegar a hora de determinar a string de conexão, nós podemos utilizar um artifício para obter tal informação. Obtido os detalhes o que fazemos é modificar onde é necessário. Para obter a string de conexão abra o projeto Access para o qual você precisa da string de conexão. Abra o VBE (Alt+F11) e na janela de verificação imediata digite:

?Currentproject.Connection

Na própria janela de verificação imediata, obteremos a string completa como segue (a string está quebrada para facilitar a leitura. Cada quebra ocorre onde há o ponto-e-vírgula):

Provider=Microsoft.Jet.OLEDB.4.0;

User ID=Admin;

Data Source=E:\Robert\mdbTeste.mdb;

Mode=Share Deny None;

Extended Properties="";

Jet OLEDB:System database=C:\dbsTrampo\System.mdw;

Jet OLEDB:Registry Path=Software\Microsoft\Office\11.0\Access\Jet\4.0;

Jet OLEDB:Database Password="";

Jet OLEDB:Engine Type=5;

Jet OLEDB:Database Locking Mode=1;

Jet OLEDB:Global Partial Bulk Ops=2;

Jet OLEDB:Global Bulk Transactions=1;

Jet OLEDB:New Database Password="";

Jet OLEDB:Create System Database=False;

Jet OLEDB:Encrypt Database=False;

Jet OLEDB:Don't Copy Locale on Compact=False;

Jet OLEDB:Compact Without Replica Repair=False;

Jet OLEDB:SFP=False.

Não é necessário utilizar todas as partes da conexão conforme mostrado acima. Neste módulo, nós estamos interessados em:

·         Provider

·         User

·         Data Source

·         Password (se houver uma senha no banco de dados)

O restante não será relevante para desenvolvermos o curso.

1.3.     Declaração de variáveis: evitando ambigüidades

Como DAO e ADO são bibliotecas destinadas à conexão de dados é de se imaginar que ambos possuirão objetos os quais são os mesmos (embora possuam diferentes propriedades e métodos). Para evitar ambigüidade no seu código, procure sempre declarar explicitamente qual biblioteca você estará usando.

Isso não somente melhora o desempenho do seu código como também lhe ajudará a identificar os objetos sendo declarados e usados. Por exemplo, para evitar ambigüidade entre os recordsets de uma e de outra biblioteca, faríamos:

Sub declarandoVariáveis()

    Dim daoRs  As DAO.Database

    Dim adoRs  As ADODB.Recordset

End Sub

O nome da variável é menos importante do que o objeto ao qual ele se refere. Por exemplo, eu geralmente declaro um recordset como sendo apenas um rs sem prefixá-lo com ado ou dao como fiz acima. Isso porque o objeto está claro logo a seguir, mas caso seja necessário é uma opção a ser considerada, pois reduz mais ainda as chances de confusão entre os objetos.

1.4.     Cursores “server-side” vs “client-side”

Quando usamos ADO podemos escolher entre os cursores “server-side” (lado do servidor) e “client-side” (lado do cliente). O cursor “server-side” é o padrão do ADO.

A grande diferença entre um cursor e outro diz respeito ao local onde os dados contidos em um recordset são “cached” (armazenados). No caso do “server-side” isso ocorre no servidor ao passo que o “client-side” ocorre no cliente.

Assim, se o cursor é “server-side”, quanto mais usuários estiverem conectados, mais estresse e colocado no servidor, pois mais recursos são exigidos dele para servir a todos os clientes. Por outro lado, no caso do “client-side” o armazenamento ocorre localmente o que reduz o estresse colocado no servidor. No caso do “client-side”, isso implica mais rapidez no acesso aos dados uma vez que os mesmos estejam armazenados localmente.

Testes de desempenho apontam para o uso de cursores “server-side” para instruções como INSERT, UPDATE e DELETE, pois liberam recursos do servidor após a execução. Por outro lado, instruções como SELECT e SELECT UNION são mais apropriadas para “client-side”, pois o armazenamento consome recursos do cliente e não do servidor.

Existem tipos de fonte de dados que não aceitam cursores “server-side” e nestes casos precisaríamos utilizam “client-side”, não obstante se estamos trabalhando com Access via Excel isso passa a ser irrelevante se o programa sendo desenvolvido é stand-alone.

1.5.     O que o leitor precisa fazer antes de continuar

Antes de continuar a leitura é importante que o leitor instale as referências ao ADO e ADOX. Para tanto, siga os passos abaixo:

·         Abra o VBE (Alt+F11);

·         Clique em Ferramentas à Referências;

·         Procure e selecione na lista as sequintes referências:

o   Microsoft ActiveX Data Objects X.x Library

o   Microsoft ADO Ext. X.x. for DLL and Security

O X.x indica a versão (para Office 2003 com as atualizações a versão é 2.8).