Connectivité de base de données ouverte - Open Database Connectivity

En informatique , Open Database Connectivity ( ODBC ) est une interface de programmation d'applications (API) standard permettant d'accéder aux systèmes de gestion de bases de données (SGBD). Les concepteurs d'ODBC visaient à le rendre indépendant des systèmes de bases de données et des systèmes d'exploitation . Une application écrite à l'aide d'ODBC peut être portée sur d'autres plates-formes, à la fois côté client et côté serveur, avec peu de modifications du code d'accès aux données.

ODBC assure l'indépendance du SGBD en utilisant un pilote ODBC comme couche de traduction entre l'application et le SGBD. L'application utilise les fonctions ODBC via un gestionnaire de pilotes ODBC avec lequel elle est liée, et le pilote transmet la requête au SGBD. Un pilote ODBC peut être considéré comme un pilote d'imprimante ou un autre pilote, fournissant un ensemble standard de fonctions à utiliser par l'application et implémentant des fonctionnalités spécifiques au SGBD. Une application qui peut utiliser ODBC est appelée « compatible ODBC ». Toute application compatible ODBC peut accéder à tout SGBD pour lequel un pilote est installé. Des pilotes existent pour tous les principaux SGBD, de nombreuses autres sources de données telles que les systèmes de carnet d'adresses et Microsoft Excel , et même pour les fichiers texte ou de valeurs séparées par des virgules (CSV).

ODBC a été développé à l'origine par Microsoft et Simba Technologies au début des années 1990 et est devenu la base de l' interface de niveau d'appel (CLI) normalisée par SQL Access Group dans le domaine Unix et mainframe . ODBC a conservé plusieurs fonctionnalités qui ont été supprimées dans le cadre de l'effort CLI. L'ODBC complet a ensuite été réintégré sur ces plates-formes et est devenu un standard de facto considérablement mieux connu que CLI. L'interface de ligne de commande reste similaire à ODBC et les applications peuvent être portées d'une plate-forme à l'autre avec peu de modifications.

Histoire

Avant ODBC

L'introduction de la base de données relationnelle basée sur l' ordinateur central au cours des années 1970 a conduit à une prolifération des méthodes d'accès aux données. Généralement, ces systèmes fonctionnaient avec un simple processeur de commandes qui permettait aux utilisateurs de taper des commandes de type anglais et de recevoir une sortie. Les exemples les plus connus sont SQL d' IBM et QUEL du projet Ingres . Ces systèmes peuvent ou non permettre à d'autres applications d'accéder directement aux données, et à celles qui ont utilisé une grande variété de méthodologies. L'introduction de SQL visait à résoudre le problème de la normalisation du langage , bien que des différences substantielles dans la mise en œuvre subsistaient.

Étant donné que le langage SQL n'avait que des fonctionnalités de programmation rudimentaires, les utilisateurs voulaient souvent utiliser SQL dans un programme écrit dans un autre langage, par exemple Fortran ou C . Cela a conduit au concept d' Embedded SQL , qui a permis d' incorporer du code SQL dans un autre langage. Par exemple, une instruction SQL comme pourrait être insérée sous forme de texte dans le code source C, et lors de la compilation, elle serait convertie dans un format personnalisé qui appellerait directement une fonction dans une bibliothèque qui transmettrait l'instruction au système SQL. Les résultats renvoyés par les instructions seraient réinterprétés dans des formats de données C, comme l' utilisation d'un code de bibliothèque similaire. SELECT * FROM citychar *

L'approche Embedded SQL présentait plusieurs problèmes. Comme les différentes variétés de SQL, les requêtes SQL incorporés qui les ont utilisés variaient considérablement, non seulement de la plate - forme à plate - forme, mais même dans plusieurs langues sur une plate - forme - un système que les appels autorisés dans IBM de DB2 serait très différent de celui qui a appelé en leur propre SQL/DS . Un autre problème clé du concept Embedded SQL était que le code SQL ne pouvait être modifié que dans le code source du programme, de sorte que même de petites modifications de la requête nécessitaient un effort considérable du programmeur pour la modifier. Le marché SQL appelait cela SQL statique , par opposition à SQL dynamique qui pouvait être modifié à tout moment, comme les interfaces de ligne de commande livrées avec presque tous les systèmes SQL, ou une interface de programmation qui laissait le SQL en texte brut jusqu'à ce qu'il soit appelé. . Les systèmes SQL dynamiques sont devenus une priorité pour les fournisseurs de SQL au cours des années 1980.

Les bases de données mainframe plus anciennes et les nouveaux systèmes basés sur des micro-ordinateurs basés sur elles n'avaient généralement pas de processeur de commandes de type SQL entre l'utilisateur et le moteur de base de données. Au lieu de cela, les données étaient accessibles directement par le programme - une bibliothèque de programmation dans le cas de grands systèmes centraux, ou une interface de ligne de commande ou un système de formulaires interactifs dans le cas de dBASE et d'applications similaires. Les données de dBASE n'étaient généralement pas accessibles directement par d'autres programmes exécutés sur la machine. Ces programmes peuvent avoir un moyen d'accéder à ces données, souvent via des bibliothèques, mais cela ne fonctionnerait avec aucun autre moteur de base de données, ni même différentes bases de données dans le même moteur. En effet, tous ces systèmes étaient statiques, ce qui présentait des problèmes considérables.

Premiers efforts

Au milieu des années 1980, l'amélioration rapide des micro-ordinateurs, et en particulier l'introduction de l' interface utilisateur graphique et des programmes d'application riches en données comme Lotus 1-2-3, ont suscité un intérêt croissant pour l'utilisation des ordinateurs personnels comme plate-forme côté client de choix. en informatique client-serveur . Dans ce modèle, les gros ordinateurs centraux et les mini - ordinateurs seraient principalement utilisés pour fournir des données sur des réseaux locaux à des micro-ordinateurs qui interpréteraient, afficheraient et manipuleraient ces données. Pour que ce modèle fonctionne, une norme d'accès aux données était une exigence - dans le domaine de l'ordinateur central, il était très probable que tous les ordinateurs d'un magasin provenaient d'un seul fournisseur et que les clients étaient des terminaux informatiques qui leur parlaient directement, mais dans le domaine micro, il n'existait pas une telle normalisation et n'importe quel client pouvait accéder à n'importe quel serveur en utilisant n'importe quel système de réseau.

À la fin des années 1980, plusieurs efforts étaient en cours pour fournir une couche d'abstraction à cette fin. Certains d'entre eux étaient liés à l'ordinateur central, conçus pour permettre aux programmes exécutés sur ces machines de se traduire entre la variété de SQL et de fournir une interface commune unique qui pourrait ensuite être appelée par d'autres programmes d'ordinateur central ou de micro-ordinateur. Ces solutions incluses architecture Distributed Relational Database d'IBM ( DRDA ) et Apple Computer de l' accès aux données Langue . Beaucoup plus courants, cependant, étaient les systèmes qui fonctionnaient entièrement sur des micro-ordinateurs, y compris une pile de protocoles complète qui incluait tout support de mise en réseau ou de traduction de fichiers requis.

L' un des premiers exemples d'un tel système était Lotus Development de DataLens , d' abord connu sous le nom Blueprint. Blueprint, développé pour 1-2-3, a pris en charge une variété de sources de données, y compris SQL/DS, DB2, FOCUS et une variété de systèmes mainframe similaires, ainsi que des systèmes de micro-ordinateurs comme dBase et les premiers efforts de Microsoft/Ashton-Tate qui finirait par devenir Microsoft SQL Server . Contrairement au dernier ODBC, Blueprint était un système purement basé sur du code, dépourvu de tout ce qui se rapprochait d'un langage de commande comme SQL. Au lieu de cela, les programmeurs utilisaient des structures de données pour stocker les informations de la requête, construisant une requête en liant plusieurs de ces structures entre elles. Lotus a qualifié ces structures composées d' arbres de requêtes .

À peu près à la même époque, une équipe de l'industrie comprenant des membres de Sybase (Tom Haggin), Tandem Computers ( Jim Gray et Rao Yendluri) et Microsoft (Kyle G) travaillait sur un concept SQL dynamique standardisé. Une grande partie du système était basée sur le système DB-Library de Sybase, avec la suppression des sections spécifiques à Sybase et plusieurs ajouts pour prendre en charge d'autres plates-formes. DB-Library a été aidée par le passage à l'échelle de l'industrie des systèmes de bibliothèque étroitement liés à une langue spécifique à des systèmes de bibliothèque fournis par le système d'exploitation et nécessitant que les langues de cette plate-forme soient conformes à ses normes. Cela signifiait qu'une seule bibliothèque pouvait être utilisée avec (potentiellement) n'importe quel langage de programmation sur une plate-forme donnée.

La première version de l' API Microsoft Data Access a été publiée en avril 1989, à peu près en même temps que l'annonce de Blueprint par Lotus. Malgré la grande avance de Blueprint – il fonctionnait lorsque MSDA était encore un projet papier – Lotus a finalement rejoint les efforts de MSDA car il est devenu clair que SQL deviendrait la norme de facto pour les bases de données. Après une contribution considérable de l'industrie, à l'été 1989, la norme est devenue SQL Connectivity ( SQLC ).

SAG et CLI

En 1988, plusieurs fournisseurs, principalement issus des communautés Unix et des bases de données, ont formé le SQL Access Group (SAG) dans le but de produire une norme de base unique pour le langage SQL. Lors de la première réunion, il y a eu un débat considérable sur la question de savoir si l'effort devrait ou non travailler uniquement sur le langage SQL lui-même, ou tenter une normalisation plus large qui comprenait également un système d'intégration de langage SQL dynamique, ce qu'ils ont appelé une interface de niveau d'appel (CLI) . Tout en assistant à la réunion avec une première ébauche de ce qui était alors encore connu sous le nom de MS Data Access, Kyle Geiger de Microsoft a invité Jeff Balboni et Larry Barnes de Digital Equipment Corporation (DEC) à se joindre également aux réunions du SQLC. SQLC était une solution potentielle à l'appel de la CLI, qui était dirigé par DEC.

Le nouveau "gang de quatre" SQLC, MS, Tandem, DEC et Sybase, a apporté une version mise à jour de SQLC à la prochaine réunion du SAG en juin 1990. Le SAG a répondu en ouvrant l'effort standard à toute conception concurrente, mais parmi les nombreuses propositions , seul Oracle Corp disposait d'un système qui présentait une concurrence sérieuse. En fin de compte, SQLC a remporté les votes et est devenu le projet de norme, mais seulement après que de grandes parties de l'API ont été supprimées - le document de normes a été réduit de 120 pages à 50 pendant cette période. C'est également au cours de cette période que le nom Call Level Interface a été formellement adopté. En 1995, SQL/CLI est devenu une partie de la norme internationale SQL, ISO/IEC 9075-3. Le SAG lui - même a été repris par le X / Open groupe en 1996, et, au fil du temps, est devenu une partie de l'Open Group de l' environnement d' application commune .

MS a continué à travailler avec la norme SQLC d'origine, en conservant de nombreuses fonctionnalités avancées qui ont été supprimées de la version CLI. Celles-ci comprenaient des fonctionnalités telles que des curseurs défilants et des requêtes d'informations sur les métadonnées . Les commandes de l'API ont été divisées en groupes ; le groupe Core était identique à la CLI, les extensions de niveau 1 étaient des commandes faciles à implémenter dans les pilotes, tandis que les commandes de niveau 2 contenaient les fonctionnalités les plus avancées comme les curseurs. Une proposition de norme a été publiée en décembre 1991, et les commentaires de l'industrie ont été recueillis et intégrés au système jusqu'en 1992, ce qui a entraîné un autre changement de nom pour ODBC .

JET et ODBC

Pendant ce temps, Microsoft était en train de développer son système de base de données Jet . Jet a combiné trois sous-systèmes principaux; un moteur de base de données basé sur ISAM (également nommé Jet , ce qui prête à confusion), une interface basée sur C permettant aux applications d'accéder à ces données, et une sélection de bibliothèques de liens dynamiques (DLL) de pilotes qui permettaient à la même interface C de rediriger les entrées et les sorties vers d'autres bases de données ISAM, comme Paradox et xBase . Jet autorisait l'utilisation d'un ensemble d'appels pour accéder aux bases de données de micro-ordinateurs communes d'une manière similaire à Blueprint, puis renommé DataLens. Cependant, Jet n'a pas utilisé SQL ; comme DataLens, l'interface était en C et se composait de structures de données et d'appels de fonction.

Les efforts de normalisation SAG ont offert à Microsoft l'opportunité d'adapter son système Jet à la nouvelle norme CLI. Cela ferait non seulement de Windows une plate-forme de premier plan pour le développement CLI, mais permettrait également aux utilisateurs d'utiliser SQL pour accéder à la fois à Jet et à d'autres bases de données. Ce qui manquait, c'était l'analyseur SQL qui pouvait convertir ces appels de leur forme texte dans l'interface C utilisée dans Jet. Pour résoudre ce problème, MS s'est associé à PageAhead Software pour utiliser son processeur de requêtes existant, SIMBA. SIMBA a été utilisé comme analyseur syntaxique au-dessus de la bibliothèque C de Jet, transformant Jet en une base de données SQL. Et parce que Jet pouvait transférer ces appels basés sur C vers d'autres bases de données, cela permettait également à SIMBA d'interroger d'autres systèmes. Microsoft a inclus des pilotes pour Excel pour transformer ses feuilles de calcul en tables de base de données accessibles par SQL.

Sortie et développement continu

ODBC 1.0 a été publié en septembre 1992. À l'époque, il y avait peu de prise en charge directe des bases de données SQL (par rapport à ISAM), et les premiers pilotes étaient réputés pour leurs performances médiocres. Une partie de cela était inévitable en raison du chemin emprunté par les appels à travers la pile basée sur Jet ; Les appels ODBC aux bases de données SQL ont d'abord été convertis du dialecte SQL de Simba Technologies au format interne basé sur C de Jet, puis transmis à un pilote pour être reconvertis en appels SQL pour la base de données. Digital Equipment et Oracle ont tous deux confié à Simba Technologies le développement de pilotes pour leurs bases de données.

Vers 1993, OpenLink Software a livré l'un des premiers pilotes ODBC tiers développés indépendamment, pour le SGBD PROGRESS , et a rapidement suivi avec leur SDK UDBC (un équivalent API multiplateforme d'ODBC et du SAG/CLI) et les pilotes associés pour PROGRESS. , Sybase, Oracle et autres SGBD, pour une utilisation sur un système d'exploitation de type Unix ( AIX , HP-UX , Solaris , Linux , etc.), VMS , Windows NT , OS/2 et d'autres systèmes d'exploitation.

Pendant ce temps, l'effort de standardisation de la CLI traînait en longueur et ce n'est qu'en mars 1995 que la version définitive a été finalisée. À ce moment-là, Microsoft avait déjà accordé à Visigenic Software une licence de code source pour développer ODBC sur des plates-formes non Windows. Visigenic a porté ODBC sur Mac OS et une grande variété de plates-formes Unix, où ODBC est rapidement devenu la norme de facto. La « vraie » CLI est rare aujourd'hui. Les deux systèmes restent similaires et de nombreuses applications peuvent être portées d'ODBC vers CLI avec peu ou pas de modifications.

Au fil du temps, les fournisseurs de bases de données ont repris les interfaces des pilotes et ont fourni des liens directs vers leurs produits. Ignorer les conversions intermédiaires vers et depuis Jet ou des wrappers similaires a souvent entraîné des performances plus élevées. Cependant, à ce moment-là, Microsoft avait changé d'orientation vers son concept OLE DB (récemment rétabli ), qui offrait un accès direct à une plus grande variété de sources de données, des carnets d'adresses aux fichiers texte. Plusieurs nouveaux systèmes ont suivi, qui ont encore détourné leur attention d'ODBC, notamment ActiveX Data Objects (ADO) et ADO.net , qui ont plus ou moins interagi avec ODBC au cours de leur vie.

Alors que Microsoft détournait son attention de travailler directement sur ODBC, le domaine Unix l'embrassait de plus en plus. Cela a été propulsé par deux changements au sein du marché, l'introduction d' interfaces utilisateur graphiques (GUI) comme GNOME qui ont fourni un besoin d'accéder à ces sources sous une forme non textuelle, et l'émergence de systèmes de bases de données logiciels ouverts comme PostgreSQL et MySQL , initialement sous Unix. L'adoption ultérieure d'ODBC par Apple pour l'utilisation du package iODBC standard côté Unix Mac OS X 10.2 (Jaguar) (que OpenLink Software fournissait indépendamment pour Mac OS X 10.0 et même Mac OS 9 depuis 2001) a renforcé ODBC en tant que norme pour un accès aux données multiplateforme.

Sun Microsystems a utilisé le système ODBC comme base de son propre standard ouvert, Java Database Connectivity (JDBC). Dans la plupart des cas, JDBC peut être considéré comme une version d'ODBC pour le langage de programmation Java au lieu de C . Les ponts JDBC vers ODBC permettent aux programmes basés sur Java d'accéder à des sources de données via des pilotes ODBC sur des plates-formes dépourvues de pilote JDBC natif, bien que ceux-ci soient maintenant relativement rares. Inversement, les ponts ODBC vers JDBC permettent aux programmes basés sur C d'accéder aux sources de données via les pilotes JDBC sur les plates-formes ou à partir de bases de données dépourvues de pilotes ODBC appropriés.

ODBC aujourd'hui

ODBC reste largement utilisé aujourd'hui, avec des pilotes disponibles pour la plupart des plates-formes et la plupart des bases de données. Il n'est pas rare de trouver des pilotes ODBC pour les moteurs de base de données qui sont destinés à être intégrés, comme SQLite , comme un moyen de permettre aux outils existants d'agir en tant que frontaux pour ces moteurs pour les tests et le débogage.

Cependant, l'essor de l' informatique client léger utilisant HTML comme format intermédiaire a réduit le besoin d'ODBC. De nombreuses plates-formes de développement Web contiennent des liens directs vers des bases de données cibles – MySQL étant très courant. Dans ces scénarios, il n'y a aucun accès côté client direct ni plusieurs systèmes logiciels clients à prendre en charge ; tout passe par l'application HTML fournie par le programmeur. La virtualisation qu'offre ODBC n'est plus une exigence forte, et le développement d'ODBC n'est plus aussi actif qu'avant. Mais si ODBC n'est plus une exigence forte pour la programmation client-serveur, il est désormais plus important pour l'accès, la virtualisation et l'intégration dans les scénarios d'analyse et de science des données. Ces nouvelles exigences se reflètent dans les nouvelles fonctionnalités ODBC 4.0 telles que les données semi-structurées et hiérarchiques, l'authentification Web et l'amélioration des performances.

Historique des versions

Historique des versions :

  • 1.0 : sortie en septembre 1992
  • 2.0 : ch. 1994
  • 2.5
  • 3.0 : ch. 1995, John Goodson d'Intersolv et Frank Pellow et Paul Cotton d'IBM ont apporté une contribution importante à ODBC 3.0
  • 3.5 : ch. 1997
  • 3.8 : ch. 2009, avec Windows 7
  • 4.0 : Développement annoncé en juin 2016 avec la première implémentation avec SQL Server 2017 publié en septembre 2017 et des pilotes de bureau supplémentaires fin 2018 spécification finale sur Github

Conducteurs et gestionnaires

Conducteurs

ODBC est basé sur le modèle de pilote de périphérique , où le pilote encapsule la logique nécessaire pour convertir un ensemble standard de commandes et de fonctions en appels spécifiques requis par le système sous-jacent. Par exemple, un pilote d'imprimante présente un ensemble standard de commandes d'impression, l'API, aux applications utilisant le système d'impression. Les appels passés à ces API sont convertis par le pilote dans le format utilisé par le matériel réel, par exemple PostScript ou PCL .

Dans le cas d'ODBC, les pilotes encapsulent de nombreuses fonctions qui peuvent être décomposées en plusieurs grandes catégories. Un ensemble de fonctions concerne principalement la recherche, la connexion et la déconnexion du SGBD avec lequel le pilote parle. Un deuxième ensemble est utilisé pour envoyer des commandes SQL du système ODBC au SGBD, en convertissant ou en interprétant toutes les commandes qui ne sont pas prises en charge en interne. Par exemple, un SGBD qui ne prend pas en charge les curseurs peut émuler cette fonctionnalité dans le pilote. Enfin, un autre ensemble de commandes, principalement utilisées en interne, est utilisé pour convertir les données des formats internes du SGBD en un ensemble de formats ODBC standardisés, basés sur les formats du langage C.

Un pilote ODBC permet à une application compatible ODBC d'utiliser une source de données , normalement un SGBD. Certains pilotes non SGBD existent, pour des sources de données telles que les fichiers CSV , en implémentant un petit SGBD à l'intérieur du pilote lui-même. Des pilotes ODBC existent pour la plupart des SGBD, notamment Oracle , PostgreSQL , MySQL , Microsoft SQL Server (mais pas pour l' édition Compact aka CE ), Sybase ASE , SAP HANA et DB2 . Étant donné que différentes technologies ont des capacités différentes, la plupart des pilotes ODBC n'implémentent pas toutes les fonctionnalités définies dans la norme ODBC. Certains pilotes offrent des fonctionnalités supplémentaires non définies par la norme.

Gestionnaire de pilotes

Les pilotes de périphériques sont normalement énumérés, configurés et gérés par une couche Manager distincte, qui peut fournir des fonctionnalités supplémentaires. Par exemple, les systèmes d'impression incluent souvent des fonctionnalités pour fournir une fonctionnalité de mise en file d' attente en plus des pilotes, fournissant ainsi une mise en file d'attente d'impression pour toute imprimante prise en charge.

Dans ODBC, le gestionnaire de pilotes (DM) fournit ces fonctionnalités. Le DM peut énumérer les pilotes installés et les présenter sous forme de liste, souvent sous une forme basée sur une interface graphique.

Mais le plus important pour le fonctionnement du système ODBC est le concept du DM d'un nom de source de données (DSN). Les DSN collectent des informations supplémentaires nécessaires pour se connecter à une source de données spécifique , par rapport au SGBD lui-même. Par exemple, le même pilote MySQL peut être utilisé pour se connecter à n'importe quel serveur MySQL, mais les informations de connexion pour se connecter à un serveur privé local sont différentes des informations nécessaires pour se connecter à un serveur public hébergé sur Internet. Le DSN stocke ces informations dans un format standardisé, et le DM les fournit au pilote lors des demandes de connexion. Le DM comprend également une fonctionnalité permettant de présenter une liste de DSN utilisant des noms lisibles par l'homme et de les sélectionner au moment de l'exécution pour se connecter à différentes ressources.

Le DM inclut également la possibilité de sauvegarder des DSN partiellement complets, avec du code et une logique pour demander à l'utilisateur toute information manquante au moment de l'exécution. Par exemple, un DSN peut être créé sans mot de passe requis. Lorsqu'une application ODBC tente de se connecter au SGBD à l'aide de ce DSN, le système s'interrompt et demande à l'utilisateur de fournir le mot de passe avant de continuer. Cela libère le développeur de l'application d'avoir à créer ce genre de code, ainsi que de savoir quelles questions poser. Tout cela est inclus dans le pilote et les DSN.

Configurations de pontage

Un pont est un type particulier de pilote : un pilote qui utilise une autre technologie basée sur des pilotes.

Ponts ODBC vers JDBC (ODBC-JDBC)

Un pont ODBC-JDBC se compose d'un pilote ODBC qui utilise les services d'un pilote JDBC pour se connecter à une base de données. Ce pilote traduit les appels de fonction ODBC en appels de méthode JDBC. Les programmeurs utilisent généralement un tel pont lorsqu'ils n'ont pas de pilote ODBC pour une base de données mais ont accès à un pilote JDBC. Exemples: OpenLink ODBC Pont-JDBC , SequeLink ODBC-JDBC Pont .

Ponts JDBC vers ODBC (JDBC-ODBC)

Un pont JDBC-ODBC se compose d'un pilote JDBC qui utilise un pilote ODBC pour se connecter à une base de données cible. Ce pilote traduit les appels de méthode JDBC en appels de fonction ODBC. Les programmeurs utilisent généralement un tel pont lorsqu'une base de données donnée n'a pas de pilote JDBC, mais est accessible via un pilote ODBC. Sun Microsystems a inclus un tel pont dans la JVM , mais l'a considéré comme une mesure provisoire alors que peu de pilotes JDBC existaient (le pont JDBC-ODBC intégré a été supprimé de la JVM dans Java 8). Sun n'a jamais conçu son pont pour des environnements de production et a généralement déconseillé son utilisation. Depuis 2008, les fournisseurs d'accès aux données indépendants proposent des ponts JDBC-ODBC qui prennent en charge les normes actuelles pour les deux mécanismes, et qui surpassent de loin la JVM intégrée. Exemples : OpenLink JDBC-ODBC Bridge , SequeLink JDBC-ODBC Bridge .

Ponts OLE DB vers ODBC

Un pont OLE DB-ODBC consiste en un fournisseur OLE DB qui utilise les services d'un pilote ODBC pour se connecter à une base de données cible. Ce fournisseur traduit les appels de méthode OLE DB en appels de fonction ODBC. Les programmeurs utilisent généralement un tel pont lorsqu'une base de données donnée n'a pas de fournisseur OLE DB, mais est accessible via un pilote ODBC. Microsoft en fournit un, MSDASQL.DLL, dans le cadre de l' ensemble de composants système MDAC , avec d'autres pilotes de base de données, pour simplifier le développement dans les langages compatibles COM (par exemple, Visual Basic ). Des tiers ont également développé de tels logiciels, notamment OpenLink Software dont le fournisseur OLE DB 64 bits pour les sources de données ODBC a comblé le vide lorsque Microsoft a initialement déprécié ce pont pour son système d'exploitation 64 bits. (Microsoft a cédé plus tard, et Windows 64 bits à partir de Windows Server 2008 et Windows Vista SP1 ont été livrés avec une version 64 bits de MSDASQL.) Exemples : OpenLink OLEDB-ODBC Bridge , SequeLink OLEDB-ODBC Bridge .

Ponts ADO.NET vers ODBC

Un pont ADO.NET-ODBC consiste en un fournisseur ADO.NET qui utilise les services d'un pilote ODBC pour se connecter à une base de données cible. Ce fournisseur traduit les appels de méthode ADO.NET en appels de fonction ODBC. Les programmeurs utilisent généralement un tel pont lorsqu'une base de données donnée n'a pas de fournisseur ADO.NET, mais est accessible via un pilote ODBC. Microsoft en fournit un dans le cadre de l' ensemble de composants système MDAC , avec d'autres pilotes de base de données, pour simplifier le développement en C# . Des tiers ont également développé de tels. Exemples: OpenLink Pont ADO.NET-ODBC , SequeLink ADO.NET-ODBC Pont .

Voir également

Les références

Bibliographie
  • Geiger, Kyle (1995). À l'intérieur d'ODBC . Microsoft Press. ISBN 9781556158155.
Citations

Liens externes