Notes
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
S’applique à : Access 2013, Office 2013
L’introduction du guide du programmeur ADO traite de la relation entre ADO et le reste de l’architecture Microsoft Data Access. OLE DB définit un ensemble d’interfaces COM qui fournissent aux applications un accès uniforme à des données stockées dans plusieurs sources d’informations. Cette approche permet aux sources de données de partager leurs données via plusieurs interfaces qui prennent en charge les fonctionnalités SGBD appropriées pour ces sources de données. L’architecture hautement performante d’OLE DB est conçue pour utiliser un modèle de services d’une grande souplesse, basée sur des composants. Au lieu d'avoir un nombre défini de couches intermédiaires entre l'application et les données, OLE DB n'utilise que le nombre de composants strictement nécessaires à la réalisation d'une tâche précise.
Supposons, par exemple, qu'un utilisateur souhaite exécuter une requête. Plusieurs scénarios sont envisageables :
Les données résident dans une base de données relationnelle pour laquelle il existe un pilote ODBC mais aucun fournisseur OLE DB natif : l'application utilise ADO pour communiquer avec le fournisseur Microsoft OLE DB pour ODBC, lequel charge ensuite le pilote ODBC approprié. Le pilote passe ensuite l'instruction SQL au système SGBD, qui extrait les données.
Les données résident dans Microsoft SQL Server, pour lequel il existe un fournisseur OLE DB natif : l'application utilise ADO pour communiquer directement avec le fournisseur OLE DB pour SQL Server. Aucun intermédiaire n'est requis.
Les données résident dans Microsoft Exchange Server, pour lequel il existe un fournisseur OLE DB mais aucun moteur de traitement des requêtes SQL : l'application utilise ADO pour communiquer avec le fournisseur OLE DB pour Microsoft Exchange et appelle un composant OLE DB, plus précisément un processeur de requêtes, pour traiter la requête.
Les données résident dans le système de fichiers Microsoft NTFS, sous forme de documents : les données sont accessibles par l'intermédiaire d'un fournisseur OLE DB natif, via le service d'indexation Microsoft, qui indexe le contenu et les propriétés des documents stockés dans le système de fichiers, ce qui permet l'exécution de recherches efficaces sur le contenu.
Dans tous les exemples qui précèdent, l'application peut exécuter des requêtes sur les données. Ainsi, un nombre minimal de composants permet de répondre aux besoins de l'utilisateur. Dans chaque cas, des composants supplémentaires ne sont utilisés qu'en cas de nécessité, et seuls les composants requis sont appelés. Ces possibilités de chargement à la demande de composants réutilisables et partageables contribuent grandement aux performances élevées associées à OLE DB.
Les fournisseurs appartiennent à deux catégories distinctes : les fournisseurs de données et les fournisseurs de services. Un fournisseur de données est propriétaire de ses données et les expose dans un format tabulaire à votre application. Un fournisseur de services encapsule un service en produisant et en consommant des données, ce qui étend les fonctionnalités de vos applications ADO. Un fournisseur de services peut être également défini comme un composant de service, qui doit fonctionner conjointement avec d’autres composants ou fournisseurs de services.
ADO offre une interface cohérente de haut niveau aux divers fournisseurs OLE DB.
Cette section contient les rubriques suivantes :