Escolher entre DAO e ADO

Escolher entre DAO e ADO

De Access 2000 em diante, o Access tem apoiado duas bibliotecas diferentes de acesso a dados, Data Access Objects (DAO) e ActiveX Data Objects (ADO) . É uma pergunta comum para os desenvolvedores acesso a brotação para pedir que as bibliotecas devem usar. Há várias considerações, mas a coisa mais importante a lembrar é que não é um ou / ou proposição. É perfeitamente possível e, possivelmente, mais desejável para misturar as duas bibliotecas na mesma aplicação e, assim, aproveitar o melhor dos dois mundos. O artigo se concentrar mais sobre quando e por que uma determinada tecnologia ser usada.
Nota: A partir do Access 2007 em diante, a biblioteca de acesso a dados padrão é chamado de "Object Library Microsoft Access Database Engine" ou ACEDAO . Embora isso tem nome diferente, é apenas uma versão mais recente do DAO com suporte para novas funcionalidades introduzidas nessas versões. Ao contrário do caso entre ADO e DAO, não se pode ter tanto ACEDAO e DAO referenciado na mesma aplicação, um ou outro deve ser escolhido. Felizmente, o resto do artigo é relevante para tanto para o resto do artigo, DAO será utilizado para se referir a ambos DAO e ACEDAO.
Deve-se também notar que DAO apoiou um modo diferente, ODBCDirect , que desde então tem sido depreciado e, portanto, não é considerado neste artigo.
Conteúdo
• 1 Padrões e Futuro
• 2 registros em Geral
o 2.1 Chatty contra Chunky
o 2.2 Tipos de registros
o 2.3 cursores
o 2.4 comportamentos de bloqueio e Opções
o 2,5 desconectado e registros In-Memory
o 2.6 Sintaxe e PassThrough SQL
• 3 Relatórios
• 4 Formas
o 4.1 Formulário / Folha de Dados e Unbound colunas contínuas
o 4.2 Multi-Table OrigemDoRegistro
o 4.3 filtragem user-driven e classificação
• 5 Controles
o 5.1 Reciclagem de registros
• 6 Prós vs Contras


Padrões e Futuro
ADO foi introduzido para acessar originalmente como um substituto para a biblioteca DAO e dependendo de qual versão do MDB foi criado, o arquivo pode referenciar ou DAO, ADO, ou ambos. A partir do Access 2007 em diante, ACEDAO agora é a referência padrão e é necessário adicionar manualmente referências ADO para empregar a sua funcionalidade. Embora ADO foi concebido para substituir DAO, Microsoft, desde então, inverteu a posição e fez DAO a biblioteca de acesso a dados abençoado para Access. Além disso, a Microsoft tem abençoado ADO.NET , que é inteiramente biblioteca de acesso a dados diferentes com pouco em comum para ADO além das três letras. Assim, é improvável que o ADO receberá qualquer desenvolvimento activo. No entanto, o Access não suporta ADO.NET, que usa . NET para ADO.NET não é uma escolha para o acesso neste momento. Mesmo sem qualquer desenvolvimento ativo, ADO tem alguns recursos interessantes para o acesso, que merece a sua inclusão até mesmo no desenvolvimento atual.

Registros em geral
A diferença no ADO e DAO é mais sentido quando usando o objeto de registros, seja como parte de automação dentro de VBA , obrigado a Formulários , Relatórios e controles que temOrigemDaLinha propriedade. Deve-se notar que, mesmo quando os objetos de acesso não contêm VBA e está vinculado a uma consulta ou tabela, um conjunto de registros é usado implicitamente. No entanto, ao ligar os objetos de acesso a interface de usuário, é sempre feito através de DAO em MDB e ACCDB . Por outro lado, a ADP implicitamente usa conjuntos de registros ADO. Para se ligar um conjunto de registos de outra biblioteca a um objecto de acesso, é necessário utilizar rotina VBA para realizar a ligação.
Chatty contra Chunky

Antes de nos aprofundarmos em detalhes de ambas as bibliotecas, pode ser útil para examinar primeiro os dois modelos gerais utilizados no acesso de dados. Para esta discussão, vamos usar o termo 'tagarela' e 'robusto'. O termo refere-se a um conjunto de registros que se comunicar com a fonte de dados. Com um conjunto de registros tagarela, o cliente manter um diálogo ativo com a fonte de dados para manter os dados em sincronia. Normalmente, isso significa que o cliente baixa as chaves necessárias para se deslocar e executar várias declarações posteriores contra o servidor para buscar uma ou poucas linhas em batch sob demanda. Por outro lado, um conjunto de registos robusto simplesmente obter o conjunto completo e não existe qualquer comunicação com a fonte de dados em seguida. Claro, há meio termo no meio, mas tendo em mente os dois modelos podem ser muito úteis para determinar o que é o tipo mais adequado de registros a ser usado para um cenário particular.
Também é útil considerar os efeitos que isso teria sobre a fonte de dados. Com um conjunto de registros tagarela, a declaração inicial que normalmente obtém as chaves ou índices únicos necessários para percorrer o conjunto de registros é certamente muito mais barato do que obter os dados de todo o conjunto de uma só vez e se encaixa no cenário em que navegar é desejado muito melhor. Os usuários não precisam esperar tanto tempo para o carregamento inicial e eles podem ter certeza que eles vão estar vendo os dados atuais. Por outro lado, se há vários usuários que usam mesma fonte de dados e todos eles usam registros tagarelas, há um potencial muito maior para a contenção de bloqueio e sobrecarregar o servidor, uma vez que tem de responder a várias pequenas solicitações que alguns grandes pedidos. Mais uma vez, não é um ou / ou proposição - tanto pode ser usado com grande vantagem e é responsabilidade do desenvolvedor para garantir o modelo correto é selecionado para uma determinada aplicação.

Tipos de registros
A tabela abaixo enumera todos os tipos disponíveis de registros, tanto para as bibliotecas ADO e DAO, ordenados a partir de leve a cara.
Tipo DAO ADO Comportamento Rolável Atualizável Veja Alterações de Outros
ForwardOnly
X X Chunky Não Não Não
SnapShot
X Chunky Sim Não Não
Mesa
X Tagarela Sim Sim N / A *
Estático
X Chunky Sim Sim Não
Dynaset
X Tagarela Sim Sim Edita e exclusões †
O conjunto de chaves
X Tagarela Sim Sim Edita e exclusões †
Dinâmico
X Tagarela Sim Sim Todas as mudanças visíveis

* Mesa-Type Recordset sempre bloquear a linha editada e não pode ser usado contra tabelas vinculadas, mesmo Jet / ACE tabelas por isso é praticamente impossível compartilhar um tipo de conjunto de registros da tabela.
† Não se aplica ao registro atual - exige tanto de navegação ou de atualização para obter as alterações. Além disso, as exclusões não são removidos do conjunto de registros e podem aparecer como # Excluídos.

Cursores
Ambas as bibliotecas 'Recordset implicitamente usa cursores para navegar pelo conjunto de registros, embora a literatura do DAO não pode usar a frase "cursor", mas o conceito ainda está presente. Além disso, deve notar-se que os cursores são distintas das utilizadas nos cursores RDBMS. Muitos desenvolvedores experientes RDBMS tendem a evitar o uso de cursores com os procedimentos armazenados quando possível e processamento dos dados como um conjunto e de forma compreensível. No entanto, os cursores como usado tanto de bibliotecas de acesso de dados são conceito inteiramente diferente a partir do cursor SQL e, portanto, não deve ser confundido.
ADO fornece aos desenvolvedores a opção de usar o cursor do lado do servidor ou o cursor do lado do cliente. No entanto, os tipos de registros disponíveis são restrito de fato, um cursor do lado do cliente permite que apenas para um tipo: Static. Usando o cursor do lado do cliente significa, basicamente, o ADO lida com a navegação e atualizações. Com o cursor do lado do servidor, a natureza exata dependerá da implementação do provedor. Pode ser o próprio prestador que age como o servidor que fornece a funcionalidade de cursor, ou pode fazer uso de cursor SQL suportado pelo RDBMS para fornecer o serviço. Assim, pode ser necessário consultar a documentação do provedor específico que está sendo usado em sua aplicação para compreender plenamente as implicações do uso de um cursor do lado do servidor.
Com DAO, tal escolha está disponível, tudo é gerenciado do lado do cliente, pelo motor de banco de dados, mesmo para tabelas vinculadas. Felizmente, o motor de banco de dados é muito eficiente na gestão dos dados e porque Dynaset de registros é o padrão, ele tende a adaptar o modelo tagarela e processando as linhas em lotes. No entanto, a eficiência é muito influenciada pelo SQL - se o problema desenvolvedor uma instrução SQL mal formadas, o motor pode ser forçado a baixar dados adicionais, possivelmente até mesmo a tabela inteira para satisfazer os registros.Assim, os desenvolvedores devem ser criterioso na-escrita consulta para permitir que o motor para entregar tanto processamento quanto possível para o servidor.

Bloqueio comportamentos e opções
Ambos DAO e ADO fornecer suporte para personalizar o comportamento de um conjunto de registros. Em caso de bloqueio, tanto DAO e ADO igualmente apoiar todos os modos de bloqueio, ReadOnly otimista e pessimista . No entanto, de travamento do DAO é completamente ignorado quando usado contra uma tabela ODBC-linked, adiando para o comportamento padrão de bloqueio da fonte de dados. Em caso de ADO, o comportamento de bloqueio está disponível desde o fornecedor de suporte esta ser utilizado. Deve notar-se que, para os comportamentos não suportados, ADO conjectura com o fornecedor escolhido, irá silenciosamente substituir as especificações com as especificações válidos mais próximos o que pode não ser sempre desejável. Assim, ao usar o ADO, é fortemente incentivado a ler-se sobre a documentação do provedor escolhido para compreender os comportamentos específicos que estão disponíveis com esse provedor.
DAO suporta o conceito de negar aos outros a ler ou escrever acesso à fonte de dados para os quais registros é aberto contra. Tal funcionalidade não está disponível com o ADO, embora possam existir soluções tais como a utilização de SQL nativo do servidor para prosseguir o fecho como exclusiva para atingir o mesmo efeito.

Desconectado e registros In-Memory
Um poderoso recurso do ADO é a capacidade de criar conjuntos de registros e, em seguida, desligue o conjunto de registros da fonte de dados. Este abre-se para muitas aplicações possíveis, incluindo, mas não limitados a:
• As alterações efectuadas no lote em vez de um-por-um (não directamente compatível com as formas)
• Simular transações em nível de formulário, permitindo aos usuários fazer alterações em vários registros antes de realmente enviar essas alterações para o banco de dados
• Obter um conjunto de registros atualizável mesmo que seja com base em registros não atualizável
• Controlar o tráfego de rede

Para fazer algo análogo no DAO normalmente exigem a criação de uma tabela temporária que requer I / O e modificar um arquivo do Access, que introduz várias complicações possíveis.
Um conjunto de registros ADO pode ser desligado usando o seguinte comando: Set rst.ActiveConnection = Nothing
ADO também permite a criação de um conjunto de registros In-Memory, que é basicamente um conjunto de registros que é criado inteiramente na memória, sem qualquer fonte para construir ou definir a estrutura. Isto pode ser muito útil para situações em que você precisa para permitir aos usuários criar sua própria estrutura para o seu processamento de dados, mas mais uma vez sem a sobrecarga de disco do banco de dados I / O e temporária que DAO exigiria.
Batch atualização de um conjunto de registros ADO vinculado a uma forma não é possível porque o Access abre a bandeira editado no evento AfterUpdate formas. Dito isto, as alterações feitas registros em um conjunto de registros desconectado pode ser processado através da criação de um novo conjunto de registros conectados e cópia de todos os registros que foram alterados. Isso funciona melhor se você usar um campo DateModified / DateEdited que é atualizado em evento AntesDeAtualizar do Form permitindo que você facilmente comparar dois conjuntos de registros para ver quais registros foram alterados.

Sintaxe SQL e PassThrough
DAO liga-se fortemente com o motor de banco de dados Access e, por essa razão, DAO de registros depende muito do motor para criar e gerenciar o conjunto de registros. Porque ele é o motor que faz o processamento, espera Jet SQL, e não pode processar diferentes dialetos do SQL, mesmo que o conjunto de registros pode ser aberta contra uma tabela ligada ea fonte de que a tabela seria considerar o SQL para ser válido. Por esta razão, DAO suporta a noção de 'PassThrough ", que permite que os desenvolvedores de passar a instrução SQL diretamente para a fonte de dados, sem o motor de banco de dados a análise do SQL. Isso pode ser um recurso poderoso, mas ele é limitado pelo fato de que PassThrough não são atualizáveis.

Com ADO, tudo é "passagem" e, portanto, a sintaxe SQL deve ser válido para o backend, ao invés de usar Jet SQL analisado pelo mecanismo de banco de dados em ODBC SQL. Sob condições adequadas, é possível criar um conjunto de registros ADO que é um conjunto de resultados de um procedimento armazenado e que ele seja totalmente atualizável. Para cenários onde um requisitos complexos é melhor servido usando procedimentos armazenados, ADO pode ser útil para fornecer uma interface interativa contra os procedimentos armazenados em vez de ter de recorrer a tabelas temporárias ou configuração formulário / subformulário complexo para suportar a mesma funcionalidade em DAO.


Relatórios
No caso de relatórios de acesso, a questão é muito simples. Como os relatórios são destinados a ser somente leitura, usando registros pedaços geralmente é a melhor escolha. Além disso, se o relatório for contra uma fonte de dados vinculada, a consulta de passagem torna-se uma excelente escolha para a condução do Relatório. Como é fornecido através da interface de acesso, há pouca razão para correr o tempo e esforço extra de escrever rotinas VBA para vincular um relatório a registros diferentes, que também não é possível de qualquer maneira.
Sob algumas circunstâncias em que um relatório contra a grande quantidade de dados criam desnecessária contenção de bloqueio, pode ser desejável a utilização de registos falador, mas mesmo assim, há meio da utilização de registos pesado que não necessitam de bloqueio, que também pode corrigir a situação.
A menos que você estiver usando um projeto de acesso a dados, relatórios não podem ser vinculados a registros ADO. Você nem vai precisar usar DAO ou então despejar o conjunto de registros ADO para uma tabela temporária e, em seguida, vincular o relatório para que a tabela temporária.


Formas
Como é típico de que as formas se destinam a ser apresentada ao usuário para fins interativos, incluindo as alterações, é uma exigência comum que o conjunto de registros é atualizável. Por esta razão, ForwardOnly e Snapshot pode ser imediatamente descartada.
De um modo geral, é normalmente necessário que a instrução SQL deve criar um conjunto de resultados, de tal forma que uma linha no conjunto de resultados pode ser rastreada até a linha original na fonte. Isto aplica-se se estamos usando DAO ou ADO. Assim, este normalmente exclui quaisquer dúvidas que não agregando, distinto, junta-se em diferentes direções, a união entre outros. Diversos desenvolvedores encontrá-lo simples para corresponder um formulário para uma tabela, usando subforms para representar as tabelas relacionadas. Isto não é para sugerir que a forma não pode ser obrigado a registros de múltipla mesa e ser atualizável, apenas as condições faz com que seja improvável que geralmente é útil fazê-lo.
Deve notar-se que o DAO suporta um subtipo de Dynaset Dynaset (instantâneo inconsistente) , que é útil na ligação de uma tabela, que tem uma relação de um para muitos e permitindo que se possa actualizar todas as colunas de ambas as tabelas. Em um tipo Dynaset Recordset, é necessário que quando a tabela de um lado é sujo, ele deve ser salvo antes das colunas que representam a tabela many-lateral pode ser sujo, o que pode ser problemático para cenários em que regra de negócio não permite a um registros do lado sem registros filho por exemplo.

Como mencionado anteriormente, ADO permite dialeto SQL nativo e, portanto, pode suportar procedimentos armazenados ou funções com valor de tabela, desde que o mesmo one-to-one regra ainda se aplicam. A capacidade de se ligar um formulário para um procedimento armazenado e ainda ser atualizável pode ser muito poderosa e característica conveniente, permitindo que os desenvolvedores para mover o processamento para o servidor e alavancar o poder do backend.
Capacidade do ADO para desconectar registros também abrir a possibilidade de criar um formulário-subformulário dosagem e as edições em conjunto para que haja uma medida de garantia de que as mudanças vão ser consistente. Esta necessidade não envolve o real Begin / Commit / Rollback que, infelizmente, é problemático contra uma forma ligada para ambas as bibliotecas e, portanto, não é totalmente ACID -compliant, mas é uma alternativa que não exija tanto esforço. A validação pode ser tratado dentro do formulário pai, por descarregamento evento, por exemplo, antes de enviar todas as alterações de volta para a fonte de dados.

Formulário / Folha de Dados e Unbound colunas contínuas
Um problema de acesso desenvolvedores rosto comum na utilização de um formulário contínuo ou folha de dados é quando a chamada necessidade de algum tipo de controle que realmente não se relacionam com os dados. Um exemplo comum é a necessidade de permitir aos usuários visualizar os registros e selecionar um número desconhecido de registros para processamento posterior, talvez para apagar ou relatar sobre ou algo parecido. Em um único formulário, que pode ser facilmente feito com um controlo independente, mas tal coisa não vai funcionar em um formulário contínuo ou folha de dados. Sob DAO, é comumente resolvido, fazendo uso de tabelas temporárias com colunas adicionais para atuar como as bandeiras e, portanto, vincular o controle a essas novas colunas.

Com ADO, registros desconectados pode ser usado para fornecer atualizações falsas e, assim, criar uma instrução SQL usando colunas estáticos para fornecer colunas adicionais para se ligar ao formulário contínuo. Porque ele é desconectado, não há nenhum problema de atualizações sendo restrito. Claro, esse uso realmente não permitir atualizações reais de volta para a fonte, sem medidas adicionais. Para a exigência de sinalização de uma série de registros, isso geralmente é suficiente, pois as bandeiras normalmente seriam descartadas, uma vez que o usuário é feito com ele.

Multi-Table OrigemDoRegistro
Em alguns cenários, o desenvolvedor pode querer construir uma forma que exibir informações adicionais de outras tabelas, mas permitir atualizações para apenas uma tabela vinculada ao formulário. Em teoria, tal coisa deve atualizável, mas, na prática, nem sempre é possível com DAO. Para manter um conjunto de registros atualizável, pode ser necessária a criação de uma série de funções definidas pelo usuário na consulta para realizar pesquisas para outras tabelas. Para uma ou duas colunas, isso deve funcionar razoavelmente bem, mas quando há mais colunas de exibição, o processo pode ficar muito caro e tornar-se ineficiente em comparação com uma instrução SQL que realmente unir as tabelas.
ADO suporta o conceito de TabelaExclusiva que permite ao desenvolvedor especificar qual tabela deve ser elegível para atualizações, e desde que ainda existe uma relação one-to-one entre a linha resultante e linha de origem, será atualizável. Isso permite ao desenvolvedor usar uma instrução SQL otimizada sem perder a capacidade de atualização.

Filtragem user-driven e classificação
Ambas as bibliotecas suportam filtragem e classificação. No entanto, alguns desenvolvedores do Access tem evitado usar a funcionalidade nativa prevista no acesso devido à sua sobrecarga muito caro. É comum para filtrar e / ou espécie emitindo instruções SQL. Em muitos casos, isso geralmente é mais rápido que usar as funcionalidades tanto das bibliotecas. No entanto, isto significa que mais tráfego de rede e a carga no servidor. Para cenários onde isso não é aceitável, os desenvolvedores podem querer garantir que a filtragem e classificação são feitas do lado do cliente com um instantâneo dos dados.

Com ADO, desconectados de registros pode ser usado em conjectura com filtragem / classificação para permitir ao usuário manipular dados para visualização / navegação sem qualquer preocupação com a carga que está sendo colocado no servidor ou consumir a largura de banda preciosa. Uma limitação é que o conjunto de registros ADO filtragem e classificação não pode ser tratado por as propriedades do formulário Filtrar e ORDER BY ou pelos menus padrão botão direito do mouse e menus ribbon fornecidas na versão não-runtime do Access. Outra limitação bastante grave é que a aplicação tanto de filtragem e classificação de um ADO resultados de registros no conjunto de registros a ser cortado para um máximo de 100 registros.
No entanto, outra limitação é que as condições dentro de filtros ADO só pode conter a palavra-chave ou no nível mais alto. Por exemplo:
Aceitável: rst.Filter = "País = 'EUA' OR País = 'UK'"
Produz Erro 3001: rst.Filter = "(País = 'EUA' e região = 'Nordeste') OR (País = 'UK' e região = 'Escócia')"

Controles
Há certos controles para os quais registros podem ser atribuídas, em geral Combobox e ListBox . Porque eles são usados para exibir valores, geralmente não há necessidade de um conjunto de registos actualizável e, portanto, é geralmente desejável utilizar o tipo leve para os controlos. Isto continua a ser verdade mesmo para Combobox que apoia evento SeNãoEstiverNaLista e permite a adição de novas entradas desde SeNãoEstiverNaLista faz um Requery implícito e, portanto, não é prejudicada pela não updatability do Recordset. Assim, geralmente é desejável para garantir que Snapshot do DAO e registros estática do ADO é usado. No entanto, para os controles que fazem referência a uma grande quantidade de dados, o modelo falante pode realmente proporcionar um melhor desempenho de modo que este deve ser mantido em consideração.

Registros de reciclagem
Algum dos controles é usado para auxiliar na navegação ou pesquisa dos registros que é uma parte do conjunto de registros do formulário. Ao invés de criar uma consulta separada, pode-se voltar a atribuir registos do formulário para o controle e, assim, economizar na viagem de volta e em cima. Tal operação é suportado por ambas as bibliotecas.

Prós vs Contras

Listados abaixo estão alguns prós e contras de cada um. Isto não deve ser considerada uma lista exaustiva.
DAO Prós:
• Rápido
• Código estável e livre de bugs
• Integra-se bem com bases de dados Access (Jet).
• Ações a conexão de acesso. Não abre uma conexão separada para o banco de dados durante a execução no Access.
• Pode lidar com as relações mestre / criança entre formulários e subformulários.
• Filtragem simples e triagem usando built-in propriedades do formulário tais como Filter, OrderBy e menus padrão botão direito do mouse e menus ribbon.
• DAO funciona quase perfeitamente com tabelas vinculadas ODBC.

DAO Contras:
• Não escala bem em outros bancos de dados
• Não escala bem para grandes conjuntos de registros (milhões de consultas + recordes com muita lógica de negócio pode levar um longo tempo)
• Tem um modelo de objeto muito profundo exigindo um monte de "." notação
• Não escala bem em interfaces web
• Não suporta registros desconectados e / ou fabricados
• Capacidade limitada para utilizar procedimentos armazenados do SQL Server (DAO usa passar por consultas que não produzem registros editáveis, ADO é recomendado para SP 's)

ADO Prós:
• Balanças para praticamente todos os bancos de dados que rodam em uma plataforma MS
• Executa rapidamente em grandes conjuntos de registros. (DAO às vezes pode superar ADO em que ele não carregar todo o conjunto de registros quando chamado pela primeira vez, mas sim carrega registros de forma incremental, apenas quando necessário. ADO trará resultados mais rápidos com as funções executadas em toda a grande de registros.)
• Funciona muito bem com as tabelas no Access que são realmente ligações a tabelas ou exibições em outros tipos de bancos de dados
• Tem alguns métodos interessantes que DAO não para o status de registros de teste
• Tem um modelo de objeto muito rasa (basicamente Comando conexão e registros)
• Suporta desligado e / ou fabricados de registros
• Suporta Batch Atualização (não compatível com as formas)
• Suporta protocolos HTTP apátridas
• Provedores disponíveis para Visual Foxpro, arquivos XML, arquivos do Excel e arquivos de texto, bem como para plataformas não-MS, como AS/400
• Suporta ANSI-92 instruções de consulta DDL, como GRANT + REVOKE.
• Pode aplicar classificar e filtrar as propriedades 'no lugar'. Não requer um objeto de registros separado para usar classificar e filtrar.
• Como DAO, os formulários podem ser vinculados a registros ADO (requer código)
• Desconectado, registros na memória pode ser construída na mosca
• Registros podem ser salvos e carregados a partir de arquivos XML e objetos de fluxo
• ADO suporta nativamente Paginação de registros através da utilização do PageSize e propriedades pagecount (formas não tem suporte embutido para isso)
• Objetos de registros pode ser derivada pela execução de um procedimento armazenado SQL Server (pode incluir parâmetros)
• Permite a criação de índices em memória através do uso do objeto do campo desejado Optimize Propriedade (afecta classificar, filtrar e encontrar métodos)

ADO Contras:
• Um pouco mais lento do que o DAO
• Realmente não funciona com Access 97 e versões anteriores
• A sintaxe é mais difícil para iniciantes
• Requer segunda biblioteca para algumas atividades de definição de dados (ADOX)
• Em um arquivo de banco de dados padrão (não uma ADP) um relatório não pode ser vinculado a um conjunto de registros ADO
• Método do filtro não permite o uso de palavras-chave OR em nada, mas o nível superior
• Método do filtro falha em registros que contêm mais de 500 campos
• Batch atualização em ADO não é compatível com formas ligadas ao ADO (lote bandeiras modificados são apagadas em caso ApósAtualizar)
• Formas obrigados a conjuntos de registos ADO não pode usar as seguintes propriedades em nível de formulário: Filter, OrderBy, RecordSource, RecordCount, Bookmark
• Formas obrigados a conjuntos de registos ADO não pode usar os campos relação mestre / Criança para manter automaticamente a forma de em sincronia
• Classificação padrão e menus / opções de filtragem não são compatíveis com as formas ligadas à ADO
• Propriedades de formulário padrão, como Bookmark e RecordCount não são compatíveis com ADO
• Apenas 100 registros são retornados se ambos filtragem e classificação são aplicadas a um conjunto de registros ADO
Mais algumas coisas a considerar.
Desde Access 2003, DAO voltou a ser a biblioteca padrão no Access. Isto inclui o Access 2007. A biblioteca ADO não é referenciado ao criar um novo. MDB ou. ACCDB em A2007. No Access 2007 Microsoft incluiu mais recursos em DAO (ACEDAO) para permitir que você trabalhe com as novas funcionalidades do motor de banco de dados avançado (. ACCDB). Notavelmente, estas características são:
Campos de pesquisa de valores múltiplos
Um campo de pesquisa multi-valor é um campo que pode armazenar vários valores relacionados para um determinado registro em um conjunto de registros incorporado.
Campos de anexo

O motor de base de dados suporte a um novo tipo de dados chamado acessório que pode ser usado para armazenar arquivos de dados. Os arquivos são compactados para o armazenamento, a menos que o arquivo que está sendo adicionado já está compactado. Há também um novo controle de anexos em Access 2007 para apoiar este tipo de dados.
Acrescente apenas os campos memo.

Os campos Memo apoiar uma nova propriedade chamada AppendOnly que é usado para rastrear o histórico de coluna para alterações de dados para o campo. Cada mudança feita a um acréscimo único campo é salva no banco de dados e podem ser recuperadas usando um novo método no objeto Access.Application chamado ColumnHistory.
Você pode vincular um formulário a um conjunto de registros ADO com base em um procedimento armazenado e / ou função com valor de tabela, e se todas as regras updatability forem atendidas, pode ser atualizável. Isso não é possível o uso de consultas de passagem DAO.

Da mesma forma, você pode usar TabelaExclusiva também fazer uma consulta atualizável multi-mesa. Isso é parcialmente verdadeiro com recordsets DAO, mas existem alguns casos em que a tabela de consulta múltipla não podem ser facilmente atualizados, mesmo que a atualização seria mapear a apenas um registro em uma tabela.