Migração DAO-ADO - Considerações

Considerações sobre a migração DAO/Jet para ADO/Jet e Access 2000

The Answer my friend is blowing in the wind...

Com a chegada da tecnologia ADO novos ventos estão soprando na área de acesso a informações , e , como diria um certo cantor - "The answer my friend is blowing in the wind... ".

As novidades sempre nos deixam excitados e curiosos , e por que não dizer temerosos pois é mais confortável ficar acomodado naquilo que já dominamos do que ter que sair novamente à luta. Surgem então muitos pensamentos: "Será que vou ter que migrar todos os meus sistemas ? " , "Será que a migração vai aumentar a performace da minha aplicação ?...", "Meu sistema esta funcionando muito bem ... Tenho medo de fazer a migração..." e por ai vai...

Vamos aqui fazer algumas considerações sobre a possibilidade de uma migração de uma aplicação usando DAO e o motor do banco de dados Jet Engine do Access para a ADO e o Jet Engine. Ou seja ,voce tem um aplicação usando DAO e acessando uma base de dados Access e vai migrar para ADO com a mesma base de dados Access.

Os modelos DAO e ADO: mais do que um simples troca de letras

DAO e ADO foram criadas para resolver problemas distintos e como tal expõem dois modelos de objetos diferentes com diferentes métodos para tratamento da correspondente fonte de dados. Tais diferenças podem sinalizar que talvez você tenha que fazer grande alterações durante uma possível migração DAO - ADO.

O modelo do objeto DAO foi criado para o Microsoft Access Jet Engine e incorpora os drivers ISAM e a conectividade ODBC fazendo a emulação para o Jet Engine. Naturalmente tudo isto ocorre a um custo de performance da sua aplicação. A DAO também permite utilizar o modo ODBCDiret com acesso aos objetos RDO com um acesso mais eficiente às fontes de dados ODBC.

O modelo do objeto ADO foi criado para trabalhar com os provedores OLE DB e é um modelo mais simples e flexível que a DAO. Pórem este modelo traz alguns problemas quando usados com um provedor OLE DB Microsoft Jet e é mais limitado do que a DAO no tratamento da funcionalidade do Jet Engine Access.

A questão do Provedor : Provedor OLE DB para Jet 3.51 ou para Jet 4.0 ?

A primeira decisão será qual provedor você irá usar. O provedor OLE DB para Jet 3.51 usa a mesma versão do Jet que o Access 97 e o Visual Basic 5.0 e 6.0 mas sua funcionalidade é limitada.

O provedor OLE DB para Jet 4.0 tem uma funcionalidade melhor , mas seu formato nativo de banco de dados é incompatível com Access 97, embora possa ler e escrever em formato de base de dados mais antigos usando um driver ISAM.

A questão dos Cursores : Client-Side ou Server-Side

A próxima decisão que você vai ter que fazer ao usar ADO, ODBC e RDO , e se, usa cursores Client-Side ou Server-Side. Se você escolher a primeira opção (client-side) O Cursor Cliente requisita os registros do Microsoft Jet e armazena-os em um arquivo temporário na sua máquina , oque vai permitir que sua aplicação tenha funcionalidade padrão da ADO : atualização em lote, recordsets desconectados, etc...

Você , no entanto, não vai poder enxergar novos registros incluidos a qualquer tabela usando um campo com autonumeração como chave primária a menos que use o método requery. E não vai poder enxergar as mudanças que outros usuários fizeram até que você requisite novamente o recordset (requery).

Ao optar pelos cursores do tipo Server-Side a funcionalidade será mais limitada. Você poderá obter um ganho de performance em certas operações tais como a movimentação de registros em um recordset e poderá enxergar os registros incluidos nas tabelas com campos autonumeração como chave primária.

A limitada funcionalidade da ADO e do Provedor OLE DB para O Jet.

O provedor OLE DB para o JET 3.51 é um provedor limitado pois não permite acesso a toda a capacidade do Microsoft Jet Engine. Ele permite : a abertura de recordsets tabela, consultas não parametrizadas , instruções SELECT parametrizadas ou não, execução de comandos SQL. Porém não armazena consultas ação e não permite acesso a fonte de dados ISAM.

O provedor OLE DB para o JET 4.0 permite um acesso mais amplo à capacidade do Microsoft Jet Engine, mas não total. Para tornar acessível certas funcionalidades do Jet Engine tais como criação de índices, tabelas, etc. e replicação você terá que referenciar em seu projeto a ADOX e a JRO. Então resumindo:

DAO 3.51 não pode usar o banco de dados Microsoft Jet 4.0 , tendo total controle sobre o Microsoft Jet 3.51 .
DAO 3.6 permite o controle sobre o Microsoft Jet 4.0 mas não expõe nenhuma das novas funcionalidades disponíveis no Microsoft Jet 4.0

A questão da Performance

A DAO faz uma utilização mais eficiente do Microsoft Jet Engine do que a ADO e muitas operações são mais rápidas se executadas sob a batuta da DAO : atualizações em lote. Além disso as chamadas para obter informação da estrutura são ineficientes quando aplicadas ao Microsoft Jet Engine. Consultas e Atualizações em tabelas com um número grande colunas será mais lenta se fosse feita com a DAO. Ou seja dependendo do tipo de ação a realizar na sua base de dados realizar a tarefa usando DAO será mais rápido do que usando ADO.

A questão da Conexão

O Microsoft Jet pode hospedar múltiplas sessões independentes dentro de um mesmo processo. Cada sessão possui chace separado para leitura. Uma sessão na DAO é representado pelo objeto DBEngine, e, todos os objetos DAO que for criado usarão a mesma sessão do Jet.

Usando OLE DB , uma sessão Jet é representada pelo objeto Data Source e podemos abrir múltiplas conexões em um único objeto Data Source.

Na ADO , o modelo do objeto OLE DB é mais simples: Uma conexão ADO consiste de um objeto Data Source OLE DB e um objeto Connection OLE DB. Isto significa que na ADO cada objeto Connection e ADO Data Control usa uma sessão separada do JET. Como o Microsoft Jet pode tratar um número limitado de sessões, se sua aplicação na migração for usar um número muito grande de ADO Data Controls os recursos do sistema entrarão em colapso. Além disto , a leitura de cada buffer tem um tempo de 5 segundos, e as alterações feitas em uma conexão somente serão visíveis após este intervalo. A DAO não tem esse problema pois todos os objetos estão usando o mesmo buffer.

A questão da distribuição

Usando DAO a quantidade de arquivos que você terá que instalar na máquina do usuário será muito menor. Já usando ADO terá que distribuir todos os arquivos referentes a ADO e OLE DB , incluindo ODBC e alguns drivers padrão além daqueles referentes ao JET. (Eu particularmente fiquei assustado quando gerei os discos de distribuição de minha primeira aplicação usando ADO.)

SQL - caracteres específicos

Os sintaxe quando usamos caracteres especiais em consultas SQL são diferentes . Na ADO temos somente dois caracteres : % que substitui o * e o _ (sublinha) : Veja uma tabela comparativa abaixo

DAO

Caractere usando	A função exercida
*	identifica qualquer string
?	identifica qualquer caractere
#	identifica digitos
[a-cf]	identifica de 'a' ate 'c' ou 'f'
[~a-c]	identifica qualquer caracter e 'a' ate 'c'

ADO

Caractere usando	A função exercida
%	identifica qualquer string
_	identifica qualquer caractere

Usando o método Find

As versões 3.51 e 4.0 do provedor OLE DB para o Microsoft Jet não implementam o método Find nativamente. Ao invés disto 'emula' um Find onde a busca é feita sequenciamente registro a registro. Quer um conselho ? Evite usar Find na ADO, use um comando SELECT com uma condição (cláusula WHERE) para retornar os registros que você precisa ou o método Filter.

A questão da segurança

Para trabalhar com mecanismo de segurança você terá que referenciar a ADOX ( uma extensão da ADO) e mesmo assim ao criar usuários no ambiente Jet você não vai poder especificar o PID. Ou seja , se o arquivo SYSTEM.MDW for excluído você não será capaz de recriar as contas desde o princípio. Por isso faça sempre um backup do SYSTEM.MDW.

A questão do Access 2000

Se você usar a base de dados no formato do Jet 4.0 , as aplicações feitas com o Visual Basic 4.0 , 5.0 e 6.0 que usam o DAO Data Control não poderão ler os dados do seu banco de dados. Além disto as consultas armazenadas criadas pela ADO não são visíveis ao Access 2000.

Agora é com você , ou , como se diz naquele chatíssimo programa : Você decide.

so long...

Veja os Destaques e novidades do SUPER DVD Visual Basic (sempre atualizado) : clique e confira !

Quer migrar para o VB .NET ?