Tira-Teima : Afinal ADO ou DAO ???

A esta altura do campeonato talvez a pergunta : Afinal o que devo usar para acessar dados em minhas aplicações Visual Basic . ADO ou DAO ? possa parecer um tanto fora de propósito , afinal , estamos em tempos de VB.NET , OOP , sem dúvida um grande avanço em relação as versões anteriores.

Mas minha experiência pessoal prefere não ignorar ou esquecer ADO ou DAO , pelo menos por enquanto, pois no dia a dia ,e , por questão de compatibilidade estas tecnologias serão ainda muito usadas.

Então vou responder a pergunta , mas antes vou acrescentar um porém , a resposta vai depender muito de cada caso particular. Vou explicar...

Se você estiver acessando um banco de dados Access 97 ou Access 2000 para manipulação de dados então a resposta é :

- Use DAO quer se vai usar ou não replicação de banco de dados

- DAO chega a ser de 1,5 a 3,0 vezes mais rápido que ADO.

Mas DAO consegue acessar o Access 2000 ? Sim . consegue .Leia  veja o artigo que escrevi em :

Acessando uma base de dados Access 2000 com DAO.

Embora na teoria a ADO tenha vindo para substituir DAO , existem muitas funcionalidades que DAO suporta que ADO não suporta. Abaixo uma relação com algumas destas funcionalidades:

Funcionalidades que funcionam com DAO e não funcionam com ADO:

• Execução de transações que usam mais de um banco de dados :

  • Funciona com DAO sem problemas pois transações estão a nível de área de trabalho (Workspace)

  • Não funciona com ADO pois transações estão a nível de conexão (Connection) e conexões suportam somente um banco de dados

• Abrir uma tabela de forma a não permitir que outros possa abrí-la também :

  • Funciona com DAO através do uso da constante DbDenyWrite

  • Não funciona com ADO a nível de tabela , pois a  constante adModeSharedDenyRead somente pode usada a nível de conexão.

• Abrir uma tabela em um modo que não permite que outros possam abrir a tabela no modo read-write :

  • Funciona com DAO através do uso da constante dbDenyWrite

  • Não funciona com ADO adModeSharedDenyWrite somente pode usada a nível de conexão.

• Criar usuários e grupos de forma a permitir que você possa recriá-los no caso da perda do arquivo MDW:

  • Funciona com DAO pois podemos usar  CreateUser/CreateGroup e especificar os PIDs.

  • Não funciona com ADO pois ela não permite a você definir os PIDs

• Criar acesso de segurança para objetos como formulários , relatórios e macros:

  • Funciona com DAO através da propriedade Permissions nos objetos Documents

  • Não funciona com ADO pois ela não mapeia propriamente as constantes esperadas para permissões para executar , ler e escrever para estes tipos de objetos

• Permitir criar uma tabela ODBC linkada que seja atualizável :

  • Funciona com DAO usando a função SQLStatistics

  • Não funciona com ADO pois não tem esta funcionalidade

• Permitir a criação de replicas "Prevent Deletes" :

  • Funciona com DAO passando o valor de &H4 para a chamada CreateReplica

  • Não funciona com ADO (não dá suporte a esta funcionalidade)

• Permitir a definição e mudança das opções Jet sem fazer alterações no registro:

  • Funciona com DAO através de DBEngine.GetOption e DBEngine.SetOption

  • Não funciona com ADO (não dá suporte a esta funcionalidade)

• Permitir a criação, alteração e exclusão de qualquer propriedade através do JPM (Jet Property Manager):

  • Funciona com DAO através de CreateProperty/Properties.Append.

  • Falha com ADO/ADOX/JRO desde que não há um hook da JPM para ADO.

• Forçar o modo locking para um banco de dados quando trabalhar com o Access:

  • Funciona com DAO através do uso das constantes DAO.LockTypeEnum enquanto usar o banco de dados atual

  • Não funciona com ADO , pois a constante ADO.LockTypeEnum falha com CurrenteProject.Connection.

• Retornar permissões implícitas para um objeto :

  • Funciona com DAO através uso da propriedade AllPermissions

  • Não funciona com ADO pois não possui esta propriedade

Nota: Clique no link para ver a tabela com referências entre DAO e ADO : DAO x ADO tabela de referência.

É por isto e por outro motivos que em aplicações para banco de dados Access , que geralmente são desenvolvidos para pequenas empresas ou para rodar em pequenas redes locais DAO funciona melhor e tem melhor desempenho que ADO.

Então por que a Microsoft veio com esta história de ADO direcionando muitos programadores a substituir a DAO ? (Veja o link para migração em : Migration from DAO to ADO )

Se DAO é melhor por que ela não continuou a evoluir ?

Eu creio que o problema é que o Jet não é mais prioridade para a Microsoft então porque melhorar algo que não é mais prioridade ????

Se não ficaram convencidos então perguntem diretamente ao dono da Microsoft...

José Carlos Macoratti