cs_frop01
Messages postés1352Date d'inscriptionlundi 27 octobre 2003StatutMembreDernière intervention19 novembre 20082 4 août 2004 à 16:01
1/ ADO c'est plus conseillé que DAO et là tu utilises le DAO
2/ t'aurais pu Insérer le code ici au lieu de faire un zip
Voici un ptit copier-coller
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.
cs_Lewiss
Messages postés47Date d'inscriptionjeudi 15 juillet 2004StatutMembreDernière intervention22 septembre 2004 4 août 2004 à 15:41
4 août 2004 à 16:01
2/ t'aurais pu Insérer le code ici au lieu de faire un zip
Voici un ptit copier-coller
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.
4 août 2004 à 15:41
Merci
Vous n'êtes pas encore membre ?
inscrivez-vous, c'est gratuit et ça prend moins d'une minute !
Les membres obtiennent plus de réponses que les utilisateurs anonymes.
Le fait d'être membre vous permet d'avoir un suivi détaillé de vos demandes et codes sources.
Le fait d'être membre vous permet d'avoir des options supplémentaires.