Je lisais un article d'aide MS Excel sur pivotcache et je me demandais ce qu'ils signifiaient par sources OLE DB et ODBC
... Vous devez utiliser la propriété CommandText au lieu de la propriété SQL, qui existe désormais principalement pour la compatibilité avec les versions antérieures de Microsoft Excel. Si vous utilisez les deux propriétés, la valeur de la propriété CommandText est prioritaire.
Pour les sources OLE DB , la propriété CommandType décrit la valeur de la propriété CommandText.
Pour les sources ODBC , la propriété CommandText fonctionne exactement comme la propriété SQL et la définition de la propriété provoque l'actualisation des données ...
J'apprécie vraiment vos réponses courtes.
Réponses:
Selon ADO: ActiveX Data Objects , un livre de Jason T. Roff, publié par O'Reilly Media en 2001 (excellent diagramme ici), il dit précisément ce que MOZILLA a dit.
(directement à partir de la page 7 de ce livre)
Il semblerait donc qu'OLE DB interagit avec les sources de données SQL via la couche de pilote ODBC.
Je ne suis pas sûr à 100% que cette image soit correcte. Les deux connexions dont je ne suis pas certain sont ADO.NET via ADO C-api, et OLE DB via ODBC vers une source de données SQL (car dans ce diagramme, l'auteur ne met pas l'accès d'OLE DB via ODBC, ce que je crois est une erreur).
la source
System.Data.SqlClient
gère le protocole TDS en code managé, en utilisant uniquement du code natif pour gérer la transmission TCP / Named Pipes / etc sur le réseau. Pour les bases de données qui n'ont pas de fournisseur géré, vous pouvez utiliserSystem.Data.OleDb
pour encapsuler OLE DB ouSystem.Data.Odbc
pour encapsuler ODBC, mais ce n'est pas recommandé.ODBC: - Uniquement pour les bases de données relationnelles (Sql Server, Oracle, etc.)
OLE DB: - Pour les bases de données relationnelles et non relationnelles. (Oracle, Sql-Server, Excel, fichiers bruts, etc.)
la source
Open Database Connectivity (ODBC) is Microsoft's strategic interface for accessing data in a heterogeneous environment of relational and non- relational database management systems.
support.microsoft.com/en-us/kb/110093Voici ma compréhension (ne faisant pas autorité):
ODBC est une norme ouverte indépendante de la technologie prise en charge par la plupart des éditeurs de logiciels. OLEDB est une API de Microsoft spécifique à la technologie de l'ère COM (COM était une technologie de composant et d'interopérabilité avant .NET)
À un moment donné, divers fournisseurs de données (par exemple, Oracle, etc.), désireux d'être compatibles avec les consommateurs de données Microsoft, ont développé des fournisseurs OLEDB pour leurs produits, mais pour la plupart, OLEDB reste un standard uniquement Microsoft. Désormais, la plupart des sources de données Microsoft autorisent à la fois l'accès ODBC et OLEDB, principalement pour la compatibilité avec les anciens consommateurs de données ODBC. En outre, il existe un fournisseur OLEDB (wrapper) pour ODBC qui permet d'utiliser OLEDB pour accéder aux sources de données ODBC si l'on le souhaite.
En termes de fonctionnalités, l'OLEDB est nettement plus riche que l'ODBC mais souffre du syndrome du «one-ring-to-rule-them-all» (trop générique, trop compliqué, sans opinion).
Dans le monde non Microsoft, les fournisseurs et clients de données ODBC sont largement utilisés et ne vont nulle part.
À l'intérieur de la bulle Microsoft, OLEDB est progressivement abandonné au profit d'API natives .NET construites au-dessus de la couche de transport native de cette source de données (par exemple TDS pour MS SQL Server).
la source
ODBC et OLE DB sont deux technologies d'accès aux données concurrentes. En ce qui concerne spécifiquement SQL Server, Microsoft les a promus tous les deux comme leur orientation future préférée - mais à des moments différents.
ODBC
ODBC est une interface standard à l'échelle de l'industrie pour accéder aux données de type table. Il a été principalement développé pour les bases de données et présente les données dans des collections d'enregistrements, dont chacun est regroupé dans une collection de champs. Chaque champ a son propre type de données adapté au type de données qu'il contient. Chaque éditeur de base de données (Microsoft, Oracle, Postgres,…) fournit un pilote ODBC pour sa base de données.
Il existe également des pilotes ODBC pour les objets qui, bien qu'ils ne soient pas des tables de base de données, sont suffisamment similaires pour que l'accès aux données de la même manière soit utile. Des exemples sont les feuilles de calcul, les fichiers CSV et les rapports en colonnes.
OLE DB
OLE DB est une technologie Microsoft pour l'accès aux données. Contrairement à ODBC, il englobe à la fois des données de type table et non-table telles que les messages électroniques, les pages Web, les documents Word et les répertoires de fichiers. Cependant, il est orienté procédure plutôt qu'objet et est considéré comme une interface assez difficile avec laquelle développer l'accès aux sources de données. Pour surmonter cela, ADO a été conçu pour être une couche orientée objet au-dessus d'OLE DB et pour fournir une manière plus simple et de plus haut niveau - bien que toujours très puissante - de l'utiliser. Le grand avantage d'ADO est que vous pouvez l'utiliser pour manipuler des propriétés spécifiques à un type donné de source de données, tout aussi facilement que vous pouvez l'utiliser pour accéder aux propriétés qui s'appliquent à tous les types de source de données. Vous n'êtes pas limité à un plus petit dénominateur commun insatisfaisant.
Bien que toutes les bases de données aient des pilotes ODBC, elles ne disposent pas toutes de pilotes OLE DB. Il existe cependant une interface disponible entre OLE et ODBC qui peut être utilisée si vous souhaitez y accéder à la manière OLE DB. Cette interface est appelée MSDASQL (fournisseur Microsoft OLE DB pour ODBC).
Technologies d'accès aux données SQL Server
Étant donné que SQL Server est (1) créé par Microsoft et (2) la plate-forme de base de données Microsoft, ODBC et OLE DB lui conviennent naturellement.
ODBC
Étant donné que toutes les autres plates-formes de bases de données avaient des interfaces ODBC, Microsoft devait évidemment en fournir une pour SQL Server. De plus, DAO, la technologie par défaut d'origine dans Microsoft Access, utilise ODBC comme moyen standard de communiquer avec toutes les sources de données externes. Cela faisait d'une interface ODBC une condition sine qua non. Le pilote ODBC version 6 pour SQL Server, publié avec SQL Server 2000, est toujours disponible. Des versions mises à jour ont été publiées pour gérer les nouveaux types de données, technologies de connexion, chiffrement, HA / DR, etc. qui sont apparus avec les versions ultérieures. Depuis le 09/07/2018, la version la plus récente est la v13.1 «Pilote ODBC pour SQL Server», publiée le 23/03/2018.
OLE DB
Il s'agit de la propre technologie de Microsoft, dont ils faisaient la promotion entre 2002 et 2005, avec sa couche ADO associée. Ils espéraient manifestement que cela deviendrait la technologie d'accès aux données de choix. (Ils ont même fait d'ADO la méthode par défaut pour accéder aux données dans Access 2002/2003.) Cependant, il est finalement devenu évident que cela n'allait pas se produire pour un certain nombre de raisons, telles que:
Pour ces raisons et d'autres , Microsoft a en fait déconseillé OLE DB en tant que technologie d'accès aux données pour les versions de SQL Server après la version 11 (SQL Server 2012). Pendant quelques années auparavant, ils produisaient et mettaient à jour SQL Server Native Client, qui prenait en charge les technologies ODBC et OLE DB. À la fin de 2012 cependant, ils ont annoncé qu'ils s'alignaient sur ODBC pour l'accès natif aux données relationnelles dans SQL Server, et ont encouragé tout le monde à faire de même. Ils ont en outre déclaré que les versions de SQL Server après la v11 / SQL Server 2012 ne prendraient pas activement en charge OLE DB!
Cette annonce a provoqué une tempête de protestations. Les gens ne comprenaient pas pourquoi la SP abandonnait soudainement une technologie à laquelle ils avaient passé des années à s'engager. En outre, SSAS / SSRS et SSIS, qui étaient des applications écrites par MS intimement liées à SQL Server, dépendaient totalement ou partiellement d'OLE DB. Encore une autre plainte était que OLE DB avait certaines fonctionnalités souhaitables qu'il semblait impossible de porter vers ODBC - après tout, OLE DB avait de nombreux points positifs.
En octobre 2017, Microsoft a cédé et officiellement abandonné OLE DB . Ils ont annoncé l'arrivée imminente d'un nouveau pilote (MSOLEDBSQL) qui aurait le jeu de fonctionnalités existant de Native Client 11 et introduirait également le basculement multi-sous-réseau et le support TLS 1.2. Le chauffeur a été libéré en mars 2018.
la source
À un niveau très basique, ce ne sont que des API différentes pour les différentes sources de données (c'est-à-dire les bases de données). OLE DB est plus récent et sans doute meilleur.
Vous pouvez en savoir plus sur les deux sur Wikipedia:
C'est-à-dire que vous pouvez vous connecter à la même base de données en utilisant un pilote ODBC ou OLE DB. La différence dans le comportement de la base de données dans ces cas est ce à quoi votre livre fait référence.
la source
Les deux sont des fournisseurs de données (API que votre code utilisera pour communiquer avec une source de données). Oledb qui a été introduit en 1998 était censé remplacer ODBC (introduit en 1992)
la source
• Août 2011: Microsoft abandonne OLE DB ( Microsoft s'aligne sur ODBC pour l'accès aux données relationnelles natives )
• Octobre 2017: Microsoft annule la valeur OLE DB ( annonce de la nouvelle version du pilote OLE DB pour SQL Server )
la source
Je ne suis pas sûr de tous les détails, mais je crois comprendre que OLE DB et ODBC sont deux API disponibles pour se connecter à différents types de bases de données sans avoir à gérer tous les détails spécifiques de mise en œuvre de chacune. Selon l'article de Wikipédia sur OLE DB , OLE DB est le successeur de Microsoft à ODBC et fournit certaines fonctionnalités que vous ne pourrez peut-être pas faire avec ODBC, telles que l'accès aux feuilles de calcul en tant que sources de base de données.
la source
Sur le site Web de Microsoft, il montre que le fournisseur OLEDB natif est appliqué directement au serveur SQL et à un autre fournisseur OLEDB appelé Fournisseur OLEDB pour ODBC pour accéder à d'autres bases de données, telles que Sysbase, DB2, etc. Il existe différents types de composants sous le fournisseur OLEDB. Voir Requêtes distribuées sur MSDN pour plus d'informations.
la source
ODBC ne fonctionne que pour les bases de données relationnelles, il ne peut pas fonctionner avec les bases de données non relationnelles telles que les fichiers Ms Excel. Où Olebd peut tout faire.
la source
Pour savoir pourquoi M $ invente OLEDB, vous ne pouvez pas comparer OLEDB avec ODBC. Au lieu de cela, vous devez comparer OLEDB avec DAO, RDO ou ADO. Ce dernier s'appuie largement sur SQL. Cependant, OLEDB s'appuie sur COM. Mais ODBC existe déjà depuis de nombreuses années, il existe donc des ponts OLEDB-ODBC pour y remédier. Je pense qu'il y a une grande image lorsque M $ invente OLEDB.
la source