Connectivité de base de données ouverte

En informatique , Open Database Connectivity ( ODBC ) est une interface de programmation d'application (API) standard permettant d'accéder aux systèmes de gestion de bases de données (SGBD). Les concepteurs d'ODBC ont cherché à le rendre indépendant des systèmes de base 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 au code d'accès aux données.

ODBC permet d'obtenir une indépendance par rapport au 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 auquel elle est liée, et le pilote transmet la requête au SGBD. Un pilote ODBC peut être considéré comme analogue à 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 dite « 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 les fichiers 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é porté sur ces plates-formes et est devenu une norme de facto beaucoup plus connue que la CLI. La CLI reste similaire à ODBC et les applications peuvent être portées d'une plate-forme à l'autre avec peu de modifications.

L'introduction de la base de données relationnelle basée sur un ordinateur central dans les années 1970 a conduit à une prolifération de méthodes d'accès aux données. En général, ces systèmes fonctionnaient avec un simple processeur de commandes qui permettait aux utilisateurs de saisir des commandes de type anglais et de recevoir des résultats. 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 ceux qui le faisaient utilisaient une grande variété de méthodologies. L'introduction de SQL visait à résoudre le problème de la normalisation du langage , même si des différences substantielles dans la mise en œuvre subsistaient.

Le langage SQL ne disposant que de fonctionnalités de programmation rudimentaires, les utilisateurs souhaitaient 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 permettait d' intégrer du code SQL dans un autre langage. Par exemple, une instruction SQL comme pouvait être insérée sous forme de texte dans un code source C, et lors de la compilation, elle était convertie dans un format personnalisé qui appelait directement une fonction dans une bibliothèque qui transmettait l'instruction au système SQL. Les résultats renvoyés par les instructions étaient interprétés dans des formats de données C comme en utilisant un code de bibliothèque similaire. SELECT * FROM citychar *

L'approche Embedded SQL posait plusieurs problèmes. Comme les différentes variétés de SQL, les Embedded SQL qui les utilisaient variaient considérablement, non seulement d'une plateforme à l'autre, mais même entre les langages d'une même plateforme : un système qui permettait des appels vers IBM Db2 serait très différent d'un système qui appelait 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 de la part du programmeur pour le modifier. Le marché du SQL appelait cela du SQL statique , par opposition au SQL dynamique qui pouvait être modifié à tout moment, comme les interfaces de ligne de commande fournies avec presque tous les systèmes SQL, ou une interface de programmation qui laissait le SQL sous forme de texte brut jusqu'à ce qu'il soit appelé. Les systèmes SQL dynamiques sont devenus une priorité majeure pour les fournisseurs de SQL au cours des années 1980.

Les bases de données mainframe plus anciennes et les systèmes micro-informatiques plus récents qui en étaient basés 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 directement accessibles par le programme – une bibliothèque de programmation dans le cas de grands systèmes mainframe, 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 ne pouvaient généralement pas être consultées directement par d'autres programmes exécutés sur la machine. Ces programmes pouvaient avoir un moyen d'accéder à ces données, souvent par le biais de bibliothèques, mais cela ne fonctionnerait pas avec un autre moteur de base de données, ni même avec des bases de données différentes dans le même moteur. En fait, tous ces systèmes étaient statiques, ce qui posait des problèmes considérables.

Au milieu des années 1980, l’amélioration rapide des micro-ordinateurs, et notamment 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 dans l’informatique client-serveur . Dans ce modèle, les grands 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 nécessaire – dans le domaine des grands ordinateurs, il était très probable que tous les ordinateurs d’un magasin proviennent d’un seul fournisseur et que les clients soient des terminaux informatiques qui leur parlent directement, mais dans le domaine des micro-ordinateurs, il n’existait pas de 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 ont été déployés pour fournir une couche d'abstraction à cette fin. Certains d'entre eux concernaient les ordinateurs centraux et étaient conçus pour permettre aux programmes exécutés sur ces machines de traduire entre les différents SQL et de fournir une interface commune unique qui pouvait ensuite être appelée par d'autres programmes d'ordinateurs centraux ou de micro-ordinateurs. Ces solutions comprenaient l'architecture de base de données relationnelle distribuée ( DRDA ) d'IBM et le langage d'accès aux données d' Apple Computer . Cependant, les systèmes fonctionnant entièrement sur des micro-ordinateurs, y compris une pile de protocoles complète incluant tout support de mise en réseau ou de traduction de fichiers requis, étaient beaucoup plus courants .

L'un des premiers exemples d'un tel système fut le DataLens de Lotus Development , initialement connu sous le nom de Blueprint. Blueprint, développé pour 1-2-3, prenait en charge une variété de sources de données, notamment 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 allaient finalement devenir Microsoft SQL Server . Contrairement au ODBC ultérieur, Blueprint était un système purement basé sur le 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 requête, construisant une requête en reliant plusieurs de ces structures entre elles. Lotus faisait référence à ces structures composées sous le nom d'arbres de requête .

À la même époque, une équipe industrielle comprenant des membres de Sybase (Tom Haggin), Tandem Computers ( Jim Gray et Rao Yendluri) et Microsoft (Kyle Geiger) travaillaient sur un concept SQL dynamique standardisé. Une grande partie du système était basée sur le système DB-Library de Sybase, avec les sections spécifiques à Sybase supprimées et plusieurs ajouts pour prendre en charge d'autres plates-formes. DB-Library a été facilitée par une évolution à l'échelle de l'industrie des systèmes de bibliothèques étroitement liés à un langage spécifique, vers des systèmes de bibliothèques fournis par le système d'exploitation et nécessitant que les langages 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 au même moment que l'annonce de Blueprint par Lotus. Malgré la grande avance de Blueprint (il fonctionnait alors que MSDA n'était encore qu'un projet sur papier), Lotus a finalement rejoint les efforts de MSDA lorsqu'il est devenu évident que SQL deviendrait la norme de base de données de facto. SQL Connectivity ( SQLC ) à l'été 1989.

En 1988, plusieurs fournisseurs, principalement issus des communautés Unix et des bases de données, formèrent 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, un débat considérable eut lieu sur la question de savoir si l'effort devait ou non porter uniquement sur le langage SQL lui-même, ou tenter une normalisation plus large qui inclurait également un système d'intégration dynamique du langage SQL, ce qu'ils appelèrent une interface de niveau d'appel (CLI). Alors qu'il assistait à 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 invita également Jeff Balboni et Larry Barnes de Digital Equipment Corporation (DEC) à se joindre aux réunions SQLC. SQLC était une solution potentielle à l'appel pour la CLI, qui était menée par DEC.

Le nouveau groupe de quatre SQLC, MS, Tandem, DEC et Sybase, présenta une version mise à jour de SQLC lors de la réunion suivante du SAG en juin 1990. Le SAG répondit en ouvrant l'effort de normalisation à toute conception concurrente, mais parmi les nombreuses propositions, seule Oracle Corp avait un système qui présentait une concurrence sérieuse. Au final, SQLC remporta les votes et devint le projet de norme, mais seulement après que de grandes parties de l'API aient été supprimées - le document de normes fut 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 fut officiellement adopté. En 1995, SQL/CLI devint une partie de la norme SQL internationale, ISO/IEC 9075-3. Le SAG lui-même fut repris par le groupe X/Open en 1996 et, au fil du temps, devint une partie de l' environnement d'application commun de l' Open Group .

Microsoft 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. Il s'agissait notamment de fonctionnalités telles que les curseurs déroulants et les requêtes d'informations sur les métadonnées . Les commandes de l'API ont été divisées en groupes ; le groupe principal é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 contributions de l'industrie ont été recueillies et intégrées au système jusqu'en 1992, ce qui a donné lieu à un autre changement de nom en ODBC .

À cette époque, Microsoft était en train de développer son système de base de données Jet . Jet combinait trois sous-systèmes principaux : un moteur de base de données basé sur ISAM (également appelé Jet , ce qui porte à 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 basées sur ISAM, comme Paradox et xBase . Jet permettait d'utiliser un ensemble d'appels pour accéder aux bases de données courantes des micro-ordinateurs d'une manière similaire à Blueprint, alors rebaptisé DataLens. Cependant, Jet n'utilisait pas SQL ; comme DataLens, l'interface était en C et se composait de structures de données et d'appels de fonctions.

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 ordre pour le développement CLI, mais permettrait également aux utilisateurs d'utiliser SQL pour accéder à Jet et à d'autres bases de données. Ce qui manquait, c'était l'analyseur SQL qui pouvait convertir ces appels de leur forme textuelle en 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 au-dessus de la bibliothèque C de Jet, transformant Jet en base de données SQL. Et comme Jet pouvait transférer ces appels basés sur C vers d'autres bases de données, cela a également permis à SIMBA d'interroger d'autres systèmes. Microsoft a inclus des pilotes pour Excel afin de transformer ses documents de feuille de calcul en tables de base de données accessibles par SQL.

ODBC 1.0 a été publié en septembre 1992. À l'époque, il n'y avait que peu de support direct pour les bases de données SQL (par rapport à ISAM), et les premiers pilotes étaient connus pour leurs faibles performances. Cela était en partie 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 étaient d'abord 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 fait appel à Simba Technologies pour développer également des 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 son SDK UDBC (un équivalent API multiplateforme d'ODBC et de SAG/CLI) et les pilotes associés pour PROGRESS , Sybase, Oracle et d'autres SGBD, pour une utilisation sur des systèmes 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, les efforts pour normaliser la CLI traînaient en longueur et ce n'est qu'en mars 1995 que la version définitive fut finalisée. À cette époque, 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 le système d'exploitation Mac OS classique et sur 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 la CLI avec peu ou pas de modifications.

Au fil du temps, les fournisseurs de bases de données ont pris en charge les interfaces des pilotes et ont fourni des liens directs vers leurs produits. Le fait d'ignorer les conversions intermédiaires vers et depuis Jet ou des wrappers similaires a souvent permis d'obtenir de meilleures performances. Cependant, à ce moment-là, Microsoft avait changé d'orientation vers son concept OLE DB ), 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, détournant encore plus leur attention d'ODBC, notamment ActiveX Data Objects (ADO) et ADO.net , qui ont plus ou moins interagi avec ODBC au cours de leur existence.

Alors que Microsoft s'est détourné de l'utilisation directe d'ODBC, le secteur Unix l'a de plus en plus adopté. Cette évolution a été favorisée par deux changements sur le marché : l'introduction d' interfaces utilisateur graphiques (GUI) comme GNOME qui ont rendu nécessaire l'accès à ces sources sous forme non textuelle, et l'émergence de systèmes de bases de données logicielles ouvertes 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) (qu'OpenLink Software fournissait indépendamment pour Mac OS X 10.0 et même Mac OS 9 depuis 2001 ) a encore renforcé ODBC comme norme pour l'accès aux données multiplateformes.

Sun Microsystems a utilisé le système ODBC comme base pour sa propre norme ouverte, 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 du langage C. Les ponts JDBC vers ODBC permettent aux programmes basés sur Java d'accéder aux sources de données via des pilotes ODBC sur des plates-formes dépourvues de pilote JDBC natif, bien que ceux-ci soient désormais relativement rares. Inversement, les ponts ODBC vers JDBC permettent aux programmes basés sur C d'accéder aux sources de données via des pilotes JDBC sur des plates-formes ou à partir de bases de données dépourvues de pilotes ODBC appropriés.

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 destinés à être intégrés, comme SQLite , afin de permettre aux outils existants d'agir comme interfaces pour ces moteurs à des fins de test et de débogage.

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

• 1.0 (1993–08) : Utilisation du processeur de requêtes SIMBA produit par PageAhead Software.
• 2.0 (1994–12) : utilisé avec ODBC 2.0.
• 3.0 (1995–10) : prend en charge Windows 95 et Windows NT Workstation ou NT Server 3.51. Seuls les pilotes 32 bits étaient inclus dans cette version.
• 3.5 (1996-10) : prend en charge le jeu de caractères codé sur deux octets (DBCS) et permet l'utilisation de noms de sources de données de fichiers (DSN). Le pilote Microsoft Access a été publié dans une version RISC pour une utilisation sur les plates-formes Alpha pour les systèmes d'exploitation Windows 95/98 et Windows NT 3.51 et versions ultérieures.
• 4.0 (fin 1998) : Prise en charge du format Unicode de Microsoft Jet Engine ainsi que compatibilité avec le format ANSI des versions antérieures.

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 effectués vers 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 divisées en plusieurs grandes catégories. Un ensemble de fonctions est principalement destiné à la recherche, à la connexion et à la déconnexion du SGBD auquel le pilote communique. Un deuxième ensemble est utilisé pour envoyer des commandes SQL du système ODBC au SGBD, en convertissant ou en interprétant 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é 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 des 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 ), Mimer SQL , Sybase ASE , SAP HANA et IBM Db2 . Étant donné que les 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.

Les pilotes de périphériques sont généralement répertoriés, configurés et gérés par une couche de gestion distincte, qui peut fournir des fonctionnalités supplémentaires. Par exemple, les systèmes d'impression incluent souvent des fonctionnalités permettant de fournir une fonction de mise en file d'attente en plus des pilotes, permettant ainsi la 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 concept de nom de source de données (DSN) du DM est plus important pour le fonctionnement du système ODBC . 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 à l'aide de noms lisibles par l'homme et de les sélectionner au moment de l'exécution pour se connecter à différentes ressources.

Le DM permet également de sauvegarder des DSN partiellement complets, avec du code et une logique permettant de 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'arrête et demande à l'utilisateur de fournir le mot de passe avant de continuer. Cela libère le développeur de l'application de la nécessité de créer ce type de code, ainsi que de la nécessité de savoir quelles questions poser. Tout cela est inclus dans le pilote et les DSN.

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

Un pont ODBC-JDBC est constitué 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 ne disposent pas d'un pilote ODBC pour une base de données mais qu'ils ont accès à un pilote JDBC. Exemples : pont ODBC-JDBC OpenLink, pont ODBC-JDBC SequeLink.

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 ne dispose pas d'un 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 les environnements de production et a généralement déconseillé son utilisation. En 2008, des fournisseurs indépendants d'accès aux données proposent des ponts JDBC-ODBC qui prennent en charge les normes actuelles pour les deux mécanismes et qui surpassent de loin le pont JDBC intégré. Exemples : OpenLink JDBC-ODBC Bridge, SequeLink JDBC-ODBC Bridge, ZappySys JDBC-ODBC Bridge.

Un pont OLE DB-ODBC se compose d'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 ne dispose pas d'un fournisseur OLE DB, mais est accessible via un pilote ODBC. Microsoft en fournit un, MSDASQL.DLL, dans le cadre du bundle 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é ce type de pont, 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éconseillé ce pont pour son système d'exploitation 64 bits. (Microsoft a ensuite cédé, 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.

Un pont ADO.NET-ODBC se compose d'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 ne dispose pas d'un fournisseur ADO.NET, mais est accessible via un pilote ODBC. Microsoft en fournit un dans le cadre du bundle 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é ce type de pont. Exemples : pont OpenLink ADO.NET-ODBC, pont SequeLink ADO.NET-ODBC.