ADO n'est pas automatiquement compatible avec le code de vos applications d'accès aux données existantes. Bien qu'ADO encapsule la fonctionnalité de DAO et RDO, vous devez convertir de nombreux éléments du langage vers la syntaxe ADO. Dans certains cas, ceci signifie uniquement une simple conversion de certaines fonctions de votre code existant. Dans d'autres cas, il peut être plus intéressant de récrire l'application en utilisant les nouvelles fonctionnalités ADO. DAO (Data Access Objects) a été la première interface orientée objet à exposer le moteur de base de données Microsoft Jet (utilisé par Microsoft Access) et à permettre aux développeurs Visual Basic de connecter directement des tables Access, ou d'autres bases de données, par l'intermédiaire d'ODBC. Le modèle DAO est particulièrement adapté aux applications de systèmes autonomes ou aux déploiements locaux, à petite échelle. RDO (Remote Data Objects) est une interface d'accès aux données orientée objet pour ODBC, combinée au style pratique de DAO, offrant une interface qui exploite virtuellement toute la flexibilité et la puissance de bas niveau d'ODBC. Le modèle RDO a pour inconvénients l'accès peu performant aux bases de données Jet ou ISAM et l'obligation d'utiliser des pilotes ODBC existants pour accéder aux bases de données relationnelles. Cependant, le modèle RDO a conquis un grand nombre de développeurs SQL Server, Oracle et d'autres bases de données relationnelles volumineuses. RDO offre les objets, les propriétés et les méthodes nécessaires pour accéder aux aspects les plus ardus des procédures stockées et des jeux de résultats complexes. ADO est le successeur des modèles DAO et RDO. Du point de vue fonctionnel, ADO 2.0 est plus proche de RDO, dont il partage généralement les mappages. ADO « aplatit » le modèle d'objet utilisé par DAO et RDO, c'est-à-dire qu'il contient moins d'objets, mais plus de propriétés, de méthodes (d'arguments) et d'événements. Par exemple, le modèle ADO n'a pas d'équivalent aux objets rdoEngine et rdoEnvironment qui exposaient les interfaces du gestionnaire de pilotes ODBC et d'hEnv. Vous ne pouvez pas non plus créer de sources de données ODBC à partir d'ADO, bien que votre interface puisse passer par le fournisseur de services ODBC OLE DB. La plupart des fonctionnalités contenues dans les modèles DAO et RDO ont été regroupées en objets uniques pour constituer un modèle d'objet beaucoup plus simple. Pour cette raison, vous pouvez éprouver au départ des difficultés à trouver l'objet, la collection, la propriété, la méthode ou l'événement ADO approprié. À la différence de DAO et RDO, bien que les objets ADO soient hiérarchiques, ils peuvent également être créés hors de la portée de la hiérarchie. Notez toutefois qu'ADO ne prend pas en charge actuellement toutes les fonctionnalités DAO. ADO inclut des fonctionnalités de type RDO pour interagir avec des sources de données OLE DB, additionnées de technologies à distance et DHTML. En général, il est probablement trop tôt dans l'évolution d'ADO pour migrer immédiatement la plupart des applications DAO (sauf, peut-être, celles utilisant ODBCDirect) vers ADO, parce qu'il n'accepte pas encore la définition de données (DDL), les utilisateurs, les groupes, etc. Toutefois, si vous utilisez DAO uniquement pour les applications client-serveur sans faire appel au moteur de base de données Jet ou DDL, vous pouvez probablement migrer vers ADO immédiatement. Le cas échéant, Microsoft fournira un composant DDL ADO pour aider la migration DAO vers ADO et un support DDL générique pour les fournisseurs OLE DB.
Vous n’avez pas trouvé la réponse que vous recherchez ?
Posez votre question