INFO : Problèmes lors de la migration de DAO/Jet vers ADO/Jet

Résumé

Si vous souhaitez migrer une application utilisant à la fois DAO et le moteur de base de données Jet en une application qui utilise ADO et le moteur de base de données Jet, vous devez examiner plusieurs problèmes avant de déterminer la faisabilité d'une telle transition.

Plus d'informations

DAO et ADO ont été conçus pour résoudre deux problèmes différents. Ils présentent ainsi deux modèles d'objet différents et des méthodes distinctes de manipulation des moteurs de données sous-jacents. Ces différences pourraient se traduire par la nécessité d'effectuer des modifications considérables lors de la migration de votre application de DAO vers ADO.


Le modèle d'objet DAO est particulièrement adapté au moteur de base de données Microsoft Jet. Microsoft Jet intègre déjà ISAM et une connectivité ODBC, et fait en sorte que les principaux fournisseurs ressemblent autant que possible au moteur Jet natif, bien que ceci s'effectue au détriment des performances. DAO dispose également d'un mode ODBCDirect qui l'autorise à héberger des objets RDO et à accéder très efficacement à des sources de données ODBC.


Le modèle d'objet ADO a été conçu pour des fournisseurs OLE DB ; il s'agit d'un modèle d'objet beaucoup plus simple et plus souple que DAO. Toutefois, sa conception architecturale pose certains problèmes lors de l'utilisation du fournisseur OLE DB pour Microsoft Jet, en outre, il s'avère être plus limité que DAO en ce qui concerne les fonctionnalités Jet prises en charge.


Cet article met en exergue plusieurs problèmes dont vous devez tenir compte en prenant la décision de migrer vos applications de DAO vers ADO.


Fournisseur : Fournisseur OLE DB pour Jet 3.51 ou 4.0

Vous devez d'abord choisir le fournisseur OLE DB à utiliser. Le fournisseur OLE DB pour Jet 3.51 utilise la même version de Jet que Microsoft Access 97 et Visual Basic versions 5.0 et 6.0, mais ses fonctionnalités sont limitées. Le fournisseur OLE DB pour Jet 4.0 possède plus de fonctionnalités, mais le format natif de sa base de données est incompatible avec Access 97, bien qu'il puisse se servir d'un pilote ISAM pour lire et écrire sur des formats de bases de données plus anciens.

Curseurs : Côté client ou côté serveur

La décision suivante que vous devez prendre pour ADO, comme pour ODBC et RDO, se rapporte à l'utilisation de curseurs côté client ou côté serveur.


Si vous optez pour des curseurs côté client, le moteur du curseur client demande les enregistrements de Microsoft Jet et les stocke en mémoire tampon dans un fichier temporaire de votre ordinateur local. Votre application dispose ainsi des fonctionnalités ADO standard, telles que des jeux d'enregistrements et des mises à jour par lot en mode déconnecté et/ou enregistrés. Cependant, vous ne serez pas en mesure de voir les nouveaux enregistrements ajoutés à une table en utilisant une colonne NuméroAuto comme la clé primaire, à moins d'actualiser les enregistrements. En outre, vous serez dans l'incapacité de voir les modifications apportées par les autres utilisateurs tant que n'aurez pas actualisé le jeu d'enregistrements.


Pour plus d'informations sur cette rubrique, consultez l'article suivant dans la Base de connaissances Microsoft :
190370 PROBLÈME : Le champ NuméroAuto n'est pas incrémenté lors de l'utilisation de ADO.
Les informations de schéma renvoyées par le fournisseur OLE DB pour Microsoft Jet 3.51 sont insuffisantes pour effectuer la mise à jour de certains jeux d'enregistrements lors de l'utilisation de curseurs côté client.


Pour plus d'informations sur cette rubrique, consultez l'article suivant dans la Base de connaissances Microsoft :
190108 PROBLÈME : Erreur lors de la mise à jour d'un curseur adUseClient basée sur une requête MDB.
Si vous utilisez des curseurs côté serveur provenant du fournisseur OLE DB pour Microsoft Jet et de l'aide du jeu de lignes, les fonctionnalités seront plus limitées. Toutefois, les performances de certaines opérations, comme le défilement des enregistrements d'un jeu d'enregistrements, seront meilleures, et vous ne serez pas tenu d'actualiser le jeu d'enregistrements pour voir les enregistrements ajoutés aux tables qui contiennent des champs NuméroAuto.

Plusieurs fournisseurs

Comme indiqué au début de l'article, DAO et Jet essaient de rendre tous les fournisseurs équivalents aux yeux du programmeur. Les inconvénients se situent au niveau des performances. Les avantages se traduisent par moins de décisions relatives à des cas spécifiques lors de la programmation. ADO présente cependant la fonctionnalité native de chaque fournisseur. Les programmes peuvent ainsi être plus efficaces si leur code fait référence à un fournisseur unique, mais pas s'il s'agit d'indiquer dans l'écriture du code qu'il est nécessaire d'accéder à plusieurs fournisseurs ; vous devrez alors utiliser des curseurs côté client pour minimiser leurs différences ou consacrer un peu plus de votre application au traitement de scénarios dédiés à des cas spéciaux où plusieurs fournisseurs présentent des fonctionnalités différentes.

Fonctionnalités limitées de ADO et du fournisseur OLE DB pour Jet

Le fournisseur OLE DB pour Jet 3.51 est un fournisseur limité. Il avait pour objet de fournir une méthode à thread sécurisée d'utilisation de Microsoft Jet avec Microsoft Internet Information Server (IIS).


Pour plus d'informations sur cette rubrique, consultez l'article suivant dans la Base de connaissances Microsoft :
222135 INFO : Utilisation de Microsoft Jet avec IIS
Il ne présente pas la totalité des capacités du moteur de base de données Microsoft Jet. Il offre la possibilité d'ouvrir des jeux d'enregistrements en fonction de tables, des requêtes non paramétrées et des instructions SELECT paramétrées ou non paramétrées. Il permet également l'exécution de commandes SQL, mais pas des requêtes d'action Microsoft Jet stockées. Il n'autorise pas l'accès à des sources de données ISAM.


Le fournisseur OLE DB pour Jet 4.0 présente la plupart des fonctionnalités de Microsoft Jet, mais pas la totalité. Outre la bibliothèque de types ADO, vous devez inclure dans votre projet des références aux bibliothèques de types ADOX et JRO (Jet and Replication Objects) pour bénéficier de fonctionnalités autres que celles des principaux objets ADO. Ceci entre principalement dans la catégorie liée à la manipulation des objets spécifiques à Access et dans celle de certains autres problèmes mentionnés ci-après.

Fonctionnalités limitées de DAO

  • DAO 3.51 ne peut pas utiliser le moteur de base de données Microsoft Jet 4.0, mais dispose d'un contrôle complet sur le moteur de base de données Microsoft Jet 3.51.
  • DAO 3.6 offre le niveau de contrôle de DAO 3.51 sur Microsoft Jet 4.0, mais ne présente aucune nouvelle fonctionnalité disponible dans Microsoft Jet 4.0.

Performances

L'utilisation du moteur de base de données Microsoft Jet est bien plus efficace avec DAO qu'avec ADO et de nombreuses opérations sont plus rapides sous DAO, parfois jusqu'à 5 ou 10 fois plus rapides, par exemple l'utilisation des mises à jour par lot. Un autre problème soulevé est que les appels effectués pour récupérer des informations de schéma s'avèrent inefficaces lorsqu'elles s'appliquent à Jet. Cela se traduit par un ralentissement de l'ordre de 30 à 80 pour cent des requêtes et des mises à jour de tables dotées d'un grand nombre de colonnes, par rapport à la requête équivalente qui se sert de DAO. Vous trouverez un exemple illustrant une utilisation inefficace de Jet par DAO dans la section suivante relative aux problèmes de connexion.

Problèmes de connexion

Microsoft Jet est en mesure d'héberger de nombreuses sessions indépendantes au sein d'un même processus. Chaque session dispose d'une charge et d'un cache de lecture distinct. L'objet DBEngine représente une session dans DAO. Par défaut, tous les objets DAO que vous créez et tous les contrôles de données DAO de Visual Basic utilisent la même session Jet.


Dans OLE DB, une session Jet est représentée par l'objet source de données. Il est possible d'ouvrir plusieurs connexions pour un seul objet source de données.


Dans ADO, le modèle d'objet OLE DB est quelque peu simplifié : un objet de connexion ADO se compose d'un objet source de données OLE DB et d'un objet de connexion OLE DB. En d'autres termes, chaque objet de connexion et chaque contrôle de données ADO utilisent une session Jet distincte dans ADO.


Ceci offre des ramifications importantes lors de la migration de votre application de DAO vers ADO. Tout d'abord, Microsoft Jet ne peut gérer qu'un nombre limité de sessions. Si votre application utilise un grand nombre de contrôles de données ADO, Jet risque de manquer de ressources. En outre, la mémoire tampon de lecture de Jet dispose d'un délai d'expiration de cinq secondes, de sorte que des modifications effectuées sur une connexion ne seront pas visibles sur une autre pendant cinq secondes. Dans DAO, ceci n'était pas un problème, puisque tous les objets se servaient de la même mémoire tampon. L'article suivant de la Base de connaissances apporte des informations supplémentaires sur cette rubrique et sur le mode de partage des connexions entre des contrôles de données afin d'éliminer les problèmes causés par plusieurs sessions Jet :


216925 PROBLÈME : Problèmes de simultanéité d'un utilisateur unique avec ADO et Jet
Une deuxième méthode d'amélioration de la simultanéité consiste à utiliser la méthode RefreshCache de l'objet JetEngine. Cet objet est représenté par le biais de la bibliothèque Microsoft JRO 2.1, disponible à partir de la version ADO 2.1 Sp1 GA. Vous pouvez télécharger ADO à partir de l'adresse suivante :


http://www.microsoft.com/data

Redistribution

Lorsque vous utilisez DAO, le nombre de fichiers que vous devez installer sur l'ordinateur client est bien réduit. L'Assistant d'installation de Visual Basic (Visual Basic 5.0 et versions antérieures) ou l'Assistant Empaquetage et déploiement (Visual Basic 6.0) se charge de la gestion. Avec ADO, vous devez redistribuer la totalité de ADO et de OLE DB, y compris ODBC, ainsi que certains pilotes par défaut autres que ceux de Microsoft Jet.

Caractères génériques

Les caractères génériques de requêtes de DAO diffèrent de ceux de ADO. DAO présente les caractères suivants à utiliser avec l'opérateur LIKE de SQL :


Caractère
Fonction
*
Correspond à n'importe quelle chaîne
?
Correspond à n'importe quel caractère
#
Correspond à n'importe quel chiffre
[a-cf]
Correspond à n'importe quel caractère de 'a' à 'c' ou 'f'
[~a-c]
Correspond à n'importe quel caractère à l'exception de ceux compris entre 'a' et 'c'

ADO présente les caractères génériques ANSI suivants :


Caractère
Fonction
%
Correspond à n'importe quelle chaîne
_
Correspond à n'importe quel caractère

Caractères génériques et requêtes stockées

Si un objet QueryDef stocké dans un fichier MDB a été créé via Access ou DAO et utilise des caractères génériques, aucun enregistrement ne sera renvoyé si son exécution se déroule sous ADO. Le fournisseur OLE DB pour Jet recompile le SQL et indique au moteur de requête qu'il doit utiliser les caractères génériques ANSI (voir le tableau précédent).


Si vous créez un objet QueryDef dans une base de données Jet 4.0 à l'aide de la procédure ADO CREATE ou des instructions CREATE VIEW et des caractères génériques ANSI, les requêtes ne s'exécuteront pas correctement sous DAO 3.6. Pour plus d'informations sur les problèmes liés aux requêtes ANSI, consultez la section « Access 2000 et la compatibilité des applications héritées », plus loin dans cet article.

Find et FindFirst

Dans ADO, la méthode Find fait l'objet de limitations :
  • aucune des versions 3.51 et 4.0 du fournisseur OLE DB pour Microsoft Jet n'implémentant de méthode Find en natif, l'aide du jeu de lignes est utilisée. Cette dernière implémente la méthode Find en parcourant les enregistrements de façon séquentielle. Pour éviter d'être pénalisé au niveau des performances, il convient d'utiliser une instruction SELECT avec une condition WHERE pour ne renvoyer que les enregistrements dont vous avez besoin et, si cela n'est pas réalisable, utilisez des curseurs côté client et la méthode Filter.
  • Contrairement à FindFirst ou à la méthode ADO Filter qui autorisent des critères de recherche complexes, la méthode Find n'autorise qu'une seule comparaison en utilisant une syntaxe réduite :


    littéral d'opérateur nomdechamp

Contrôle conteneur OLE

De nombreuses bases de données, notamment la base de données Les Comptoirs (Northwind) SQL Server 7, contiennent des images et d'autres objets enregistrés par Microsoft Access. Dans Visual Basic, il est possible de voir les images en liant le contrôle conteneur OLE au contrôle de données DAO. Toutefois, en raison de l'incompatibilité entre le contrôle conteneur OLE et le contrôle de données ADO, il n'existe aucun moyen d'accéder à ces images et de les afficher en utilisant ADO. Le contrôle conteneur OLE n'est pas utilisable sans la liaison, car la méthode GetChunk ne récupère pas les données dans un format compatible avec la méthode ReadFromFile.

Sécurité

Lorsque vous utilisez ADOX pour créer des utilisateurs dans un environnement Microsoft Jet sécurisé, vous ne pouvez pas spécifier l'identificateur produit (PID). En d'autres termes, si le fichier SYSTEM.MDW est supprimé, vous ne serez pas en mesure de recréer les comptes de toutes pièces, mais devez vous fier à un fichier SYSTEM.MDW de sauvegarde.


Access 2000 et la compatibilité des applications héritées

Trois problèmes principaux de compatibilité existent :


  • Tout d'abord, l'utilisation du format de base de données Jet 4.0 signifie que les applications héritées, telles que Access 95, Access 97, Visual Basic 4.0, 5.0 et 6.0, qui utilisent le contrôle de données DAO sont toutes codées en dur pour utiliser le format de base de données Jet 3.x et seront donc dans l'incapacité de lire des données Jet 4.0.
  • Le deuxième problème concerne les requêtes stockées créées par ADO et invisibles pour Access 2000. La raison à cela est qu'une modification a été apportée au processeur de requête Jet 4.0 afin d'améliorer sa compatibilité ANSI, notamment l'ajout de nouvelles commandes SQL. Access 2000 n'affiche même pas ces requêtes afin d'éviter toute confusion des utilisateurs. Elles peuvent néanmoins être visualisées et exécutées via DAO et ADO. Elles peuvent également être référencées dans les propriétés Form et Report RecordSource ainsi que dans les instructions SQL ; vous devrez taper le nom, car le générateur ne l'affichera pas. Le fournisseur Microsoft OLE DB pour Jet 4.0 affecte toujours une valeur non NULL à la balise ANSI. En revanche, DAO affecte toujours la valeur NULL à cette balise.
  • Le troisième problème est que Jet 4.0 ne prend pas en charge FoxPro IISAM. L'accès aux tables FoxPro doit être effectué par le biais du pilote ODBC de FoxPro. Si votre base de données Jet utilise des tables FoxPro liées et que vous effectuez une conversion vers Jet 4.0, vous devrez reconstituer les liaisons pour utiliser plutôt le pilote ODBC de FoxPro.
Propriétés

ID d'article : 225048 - Dernière mise à jour : 19 août 2003 - Révision : 1

Commentaires