Question

Je lisais un article d’aide MS Excel sur pivotcache et me demandais ce qu’ils entendaient par sources OLE DB et ODBC

  

... Vous devez utiliser le CommandText   propriété au lieu de la propriété SQL,   qui existe maintenant principalement pour   compatibilité avec les versions antérieures de   Microsoft Excel. Si vous utilisez les deux   propriétés, la propriété CommandText & # 8217; s   la valeur est prioritaire.

     

Pour les sources OLE DB , le type de commande   propriété décrit la valeur de la   Propriété CommandText.

     

Pour les sources ODBC , le CommandText   propriété fonctionne exactement comme le   Propriété SQL et définition de la propriété   provoque l'actualisation des données ...

J'apprécie vraiment vos réponses courtes.

Était-ce utile?

La solution

Selon ADO: ActiveX Data Objects , un livre de Jason T. Roff, publié par O'Reilly Media en 2001 (excellent diagramme ici), il explique précisément ce que MOZILLA a dit.

(directement de la page 7 de ce livre)

  
      
  • ODBC fournit un accès uniquement aux bases de données relationnelles
  •   
  • OLE DB fournit les fonctionnalités suivantes      
        
    • Accès aux données, quel que soit leur format ou leur emplacement
    •   
    • Accès complet aux sources de données ODBC et aux pilotes ODBC
    •   
  •   

Il semblerait donc que OLE DB interagisse avec les sources de données basées sur SQL via la couche de pilote ODBC.

alt text

Je ne suis pas sûr à 100% que cette image est correcte. Les deux connexions dont je ne suis pas certain sont ADO.NET via ADO C-api et OLE DB via ODBC vers SQL Source de données (car dans ce diagramme l'auteur ne met pas l'accès OLE DB par ODBC, ce qui, à mon avis, est une erreur).

Autres conseils

ODBC: - uniquement pour les bases de données relationnelles (serveur SQL, Oracle, etc.)

OLE DB: - Pour les bases de données relationnelles et non relationnelles. (Oracle, Sql-Server, Excel, fichiers bruts, etc.)

Voici ma compréhension (qui ne fait pas autorité):

ODBC est un standard ouvert indépendant de la technologie pris en charge par la plupart des fournisseurs de logiciels. OLEDB est une API spécifique à la technologie de Microsoft de l'époque COM (COM était une technologie d'interopérabilité et de composants avant .NET)

À un moment donné, différents fournisseurs de données (par exemple, Oracle, etc.), souhaitant être compatibles avec les utilisateurs de données Microsoft, ont développé des fournisseurs OLEDB pour leurs produits, mais l’OLEDB reste, pour l’essentiel, une norme exclusivement Microsoft. Aujourd'hui, la plupart des sources de données Microsoft autorisent les accès ODBC et OLEDB, principalement pour assurer la compatibilité avec les consommateurs de données ODBC hérités. De plus, il existe un fournisseur OLEDB (encapsuleur) pour ODBC qui permet d’utiliser OLEDB pour accéder aux sources de données ODBC s’il le souhaite.

En termes de fonctionnalités, OLEDB est bien plus riche qu’ODBC, mais souffre d’un syndrome à un anneau (une règle pour tous) (trop générique, trop compliqué, pas d’opinion).

Dans un monde autre que Microsoft, les fournisseurs de données et les clients ODBC sont largement utilisés et ne vont nulle part.

À l'intérieur de la bulle Microsoft, OLEDB est progressivement supprimé au profit des API .NET natives, construites au-dessus de la couche de transport native pour cette source de données (TDS pour MS SQL Server, par exemple).

ODBC et OLE DB sont deux technologies d’accès aux données en concurrence. En ce qui concerne plus particulièrement SQL Server, Microsoft les a tous deux promus comme leur orientation future préférée - bien que à des moments différents.

ODBC

ODBC est une interface standard dans l’industrie permettant d’accéder à des données de type table. Il a été principalement développé pour les bases de données et présente des données dans des collections d'enregistrements, chacune d'entre elles étant regroupée dans une collection de champs. Chaque champ possède son propre type de données, adapté au type de données qu’il contient. Chaque fournisseur de base de données (Microsoft, Oracle, Postgres, & # 8230;) fournit un pilote ODBC pour leur 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 des données sous forme de tableau et non sous forme de table, telles que des messages électroniques, des pages Web, des documents Word et des répertoires de fichiers. Cependant, il est davantage axé sur les procédures que sur les objets et est considéré comme une interface assez difficile pour développer l'accès aux sources de données. Pour remédier à ce problème, ADO a été conçu pour être une couche orientée objet au-dessus de la base de données OLE et pour fournir un environnement plus simple et de niveau supérieur. bien que très puissant & # 8211; façon de travailler avec elle. Le grand avantage d’ADO est que vous pouvez l’utiliser pour manipuler des propriétés spécifiques à un type de source de données donné, tout aussi facilement que vous pouvez l’utiliser pour accéder à ces propriétés qui s’appliquent à tous les types de sources de données. Vous n'êtes pas limité au plus petit dénominateur commun peu satisfaisant.

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 de la même manière que OLE DB. Cette interface s'appelle MSDASQL (fournisseur Microsoft OLE DB pour ODBC).

Technologies d'accès aux données SQL Server

Etant 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 parfaitement.

ODBC

Comme toutes les autres plates-formes de bases de données avaient des interfaces ODBC, Microsoft devait évidemment en fournir une pour SQL Server. En outre, DAO, la technologie par défaut d'origine dans Microsoft Access, utilise ODBC comme moyen standard de communication avec toutes les sources de données externes. Cela a rendu une interface ODBC une condition sine qua non. Le pilote ODBC version 6 pour SQL Server, publié avec SQL Server 2000, existe toujours. Des versions mises à jour ont été publiées pour gérer les nouveaux types de données, technologies de connexion, cryptage, HA / DR, etc. apparus avec les versions suivantes. La version la plus récente est la v13.1 & # 8220; Pilote ODBC pour SQL Server & # 8221 ;, publiée le 23/03/2018.

OLE DB

Il s’agit de la technologie de Microsoft, qu’ils promouvaient depuis 2002 environ & # 8211; 2005, avec sa couche ADO associée. Ils espéraient évidemment que cela deviendrait la technologie de choix en matière d'accès aux données. (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 ne se produirait pas pour un certain nombre de raisons, telles que:

  1. Le monde n'allait pas se convertir aux technologies Microsoft et loin d'ODBC;
  2. DAO / ODBC était plus rapide que ADO / OLE DB et était également parfaitement intégré à MS Access. Par conséquent, il n’allait pas mourir de mort naturelle;
  3. Les nouvelles technologies développées par Microsoft, notamment ADO.NET, pourrait aussi parler directement à ODBC. ADO.NET pourrait parler directement à OLE DB également (laissant ainsi ADO dans un marigot), mais ce n’était pas (contrairement à ADO) dépend uniquement de celui-ci.

Pour ces raisons, et d’autres , Microsoft obsolète OLE DB en tant que technologie d'accès aux données pour les versions SQL Server ultérieures à la v11 (SQL Server 2012). Depuis quelques années auparavant, ils produisaient et mettaient à jour SQL Server Native Client, qui prenait en charge les technologies ODBC et OLE DB. Fin 2012, toutefois, ils ont annoncé qu'ils s'aligneraient sur ODBC pour l'accès aux données relationnelles natives dans SQL Server et ont encouragé tous les autres utilisateurs à faire de même. Ils ont en outre déclaré que les versions de SQL Server postérieures à v11 / SQL Server 2012 ne prendraient pas en charge la prise en charge de la base de données OLE!

Cette annonce a provoqué une tempête de protestation. Les gens ne comprenaient pas pourquoi MS était en train de dénigrer une technologie pour laquelle ils avaient passé des années à s’engager. En outre, SSAS / SSRS et SSIS, qui étaient des applications écrites par MS et intimement liées à SQL Server, étaient totalement ou partiellement dépendants de la base de données OLE. Une autre plainte était que OLE DB présentait certaines fonctionnalités souhaitables qu’il semblait impossible de réintégrer à ODBC & # 8211; après tout, OLE DB avait beaucoup de points positifs.

En octobre 2017, Microsoft a cédé et base de données OLE officiellement non dépréciée . 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 sur plusieurs sous-réseaux et la prise en charge de TLS 1.2. Le chauffeur a été libéré en mars 2018.

À un niveau très élémentaire, il s’agit simplement d’API différentes pour les différentes sources de données (bases de données, par exemple). OLE DB est plus récent et peut-être meilleur.

Vous pouvez en savoir plus sur les deux sur Wikipedia:

  1. Base de données OLE
  2. ODBC

I.e. vous pouvez vous connecter à la même base de données à l'aide d'un pilote ODBC ou d'un pilote OLE DB. La différence dans le comportement de la base de données dans ces cas correspond à ce à quoi votre livre fait référence.

Tous deux sont des fournisseurs de données (API que votre code utilisera pour communiquer avec une source de données). Oledb, introduit en 1998, devait remplacer ODBC (introduit en 1992).

Je ne suis pas sûr de tous les détails, mais d'après ce que j'ai compris, OLE DB et ODBC sont deux API disponibles pour la connexion à différents types de bases de données sans avoir à traiter tous les détails d'implémentation spécifiques de chacun. Selon l'article de Wikipedia sur OLE DB , OLE DB est le successeur de Microsoft pour ODBC et fournit certaines fonctionnalités que vous ne pourrez peut-être pas utiliser avec ODBC, telles que l’accès aux feuilles de calcul en tant que sources de base de données.

Sur le site Web de Microsoft, il est indiqué que le fournisseur OLEDB natif est appliqué directement au serveur SQL et qu’un autre fournisseur OLEDB appelé fournisseur OLEDB pour ODBC permet d’accéder à d’autres bases de données, telles que Sysbase, DB2, etc. Il existe différents types de composants sous Fournisseur OLEDB. Voir Requêtes distribuées sur MSDN pour plus d'informations. .

• Août 2011: Microsoft désapprouve la base de données OLE ( Microsoft s'aligne sur ODBC pour un accès natif aux données relationnelles )

• Octobre 2017: Microsoft undeprecates OLE DB ( Annonce de la nouvelle version du pilote OLE DB pour SQL Server )

ODBC ne fonctionne que pour les bases de données relationnelles. Il ne peut pas fonctionner avec des bases de données non relationnelles telles que les fichiers Ms Excel. Où Olebd peut tout faire.

Pour savoir pourquoi M $ a inventé OLEDB, vous ne pouvez pas comparer OLEDB avec ODBC. Au lieu de cela, vous devez comparer OLEDB avec DAO, RDO ou ADO. Ce dernier repose en grande partie sur SQL. Cependant, OLEDB s'appuie sur COM. Mais ODBC existe déjà depuis de nombreuses années, il existe donc un pont OLEDB-ODBC pour remédier à cela. Je pense qu’il ya une grande image quand M $ invente OLEDB.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top