Conectividad de bases de datos abiertas

En informática , Open Database Connectivity ( ODBC ) es una interfaz de programación de aplicaciones (API) estándar para acceder a sistemas de gestión de bases de datos (DBMS). Los diseñadores de ODBC se propusieron hacerlo independiente de los sistemas de bases de datos y de los sistemas operativos . ^{[ cita requerida ]} Una aplicación escrita con ODBC se puede trasladar a otras plataformas, tanto del lado del cliente como del servidor, con pocos cambios en el código de acceso a los datos.

ODBC logra la independencia del DBMS al utilizar un controlador ODBC como capa de traducción entre la aplicación y el DBMS. La aplicación utiliza funciones ODBC a través de un administrador de controladores ODBC con el que está vinculada, y el controlador pasa la consulta al DBMS. Un controlador ODBC puede considerarse análogo a un controlador de impresora u otro controlador, ya que proporciona un conjunto estándar de funciones para que la aplicación las utilice e implementa una funcionalidad específica del DBMS. Una aplicación que puede utilizar ODBC se denomina "compatible con ODBC". Cualquier aplicación compatible con ODBC puede acceder a cualquier DBMS para el que esté instalado un controlador. Existen controladores para todos los DBMS principales, muchas otras fuentes de datos como los sistemas de libretas de direcciones y Microsoft Excel , e incluso para archivos de texto o de valores separados por comas (CSV).

ODBC fue desarrollado originalmente por Microsoft y Simba Technologies a principios de los años 90 y se convirtió en la base de la interfaz de nivel de llamada (CLI) estandarizada por SQL Access Group en el campo de Unix y mainframe . ODBC conservó varias características que se eliminaron como parte del esfuerzo de la CLI. ODBC completo fue trasladado posteriormente de nuevo a esas plataformas y se convirtió en un estándar de facto considerablemente más conocido que la CLI. La CLI sigue siendo similar a ODBC y las aplicaciones se pueden trasladar de una plataforma a otra con pocos cambios.

La introducción de las bases de datos relacionales basadas en mainframes durante la década de 1970 condujo a una proliferación de métodos de acceso a los datos. Generalmente, estos sistemas operaban junto con un procesador de comandos simple que permitía a los usuarios escribir comandos similares a los del inglés y recibir resultados. Los ejemplos más conocidos son SQL de IBM y QUEL del proyecto Ingres . Estos sistemas pueden permitir o no que otras aplicaciones accedan a los datos directamente, y aquellos que lo hicieron utilizaron una amplia variedad de metodologías. La introducción de SQL tuvo como objetivo resolver el problema de la estandarización del lenguaje , aunque persistieron diferencias sustanciales en la implementación.

Dado que el lenguaje SQL solo tenía características de programación rudimentarias, los usuarios a menudo querían usar SQL dentro de un programa escrito en otro lenguaje, digamos Fortran o C. Esto condujo al concepto de SQL integrado , que permitía incrustar código SQL dentro de otro lenguaje. Por ejemplo, una sentencia SQL como podría insertarse como texto dentro del código fuente de C y, durante la compilación, se convertiría a un formato personalizado que llamaría directamente a una función dentro de una biblioteca que pasaría la sentencia al sistema SQL. Los resultados devueltos de las sentencias se interpretarían nuevamente en formatos de datos de C como si se usara un código de biblioteca similar.SELECT * FROM citychar *

El enfoque de SQL integrado presentaba varios problemas. Al igual que las diferentes variedades de SQL, los SQL integrados que los utilizaban variaban ampliamente, no solo de una plataforma a otra, sino incluso entre los lenguajes de una misma plataforma: un sistema que permitiera llamadas a IBM Db2 se vería muy diferente de uno que llamara a su propio SQL/DS . ^{[ dudoso – discutir ]} Otro problema clave del concepto de SQL integrado era que el código SQL solo se podía cambiar en el código fuente del programa, de modo que incluso pequeños cambios en la consulta requerían un esfuerzo considerable del programador para modificarlo. El mercado de SQL se refería a esto como SQL estático , frente al SQL dinámico que se podía cambiar en cualquier momento, como las interfaces de línea de comandos que se incluían con casi todos los sistemas SQL, o una interfaz de programación que dejaba el SQL como texto sin formato hasta que se lo llamaba. Los sistemas SQL dinámicos se convirtieron en un foco importante para los proveedores de SQL durante la década de 1980.

Las bases de datos mainframe más antiguas y los sistemas más nuevos basados ​​en microcomputadoras que se basaban en ellas no tenían, por lo general, un procesador de comandos tipo SQL entre el usuario y el motor de la base de datos. En cambio, el acceso a los datos se hacía directamente a través del programa (una biblioteca de programación en el caso de los grandes sistemas mainframe, o una interfaz de línea de comandos o un sistema de formularios interactivos en el caso de dBASE y aplicaciones similares). Los datos de dBASE no podían ser accedidos directamente por otros programas que se ejecutaban en la máquina. A esos programas se les podía proporcionar una forma de acceder a estos datos, a menudo a través de bibliotecas, pero no funcionaba con ningún otro motor de base de datos, ni siquiera con bases de datos diferentes en el mismo motor. En efecto, todos esos sistemas eran estáticos, lo que presentaba considerables problemas.

A mediados de los años 1980, la rápida mejora de los microordenadores, y especialmente la introducción de la interfaz gráfica de usuario y de programas de aplicación ricos en datos como Lotus 1-2-3, condujeron a un creciente interés en el uso de los ordenadores personales como la plataforma preferida del lado del cliente en la informática cliente-servidor . Según este modelo, los grandes mainframes y miniordenadores se utilizarían principalmente para proporcionar datos a través de redes de área local a microordenadores que interpretarían, mostrarían y manipularían esos datos. Para que este modelo funcionara, era necesario un estándar de acceso a los datos: en el campo de los mainframes era muy probable que todos los ordenadores de una tienda fueran de un mismo proveedor y los clientes fueran terminales de ordenador que se comunicaban directamente con ellos, pero en el campo de las microcomputadoras no existía tal estandarización y cualquier cliente podía acceder a cualquier servidor utilizando cualquier sistema de red.

A finales de los años 1980 se estaban realizando varios esfuerzos para proporcionar una capa de abstracción para este propósito. Algunos de ellos estaban relacionados con mainframes, diseñados para permitir que los programas que se ejecutaban en esas máquinas tradujeran entre la variedad de SQL y proporcionaran una única interfaz común que luego pudiera ser invocada por otros programas de mainframes o microcomputadoras. Estas soluciones incluían la Arquitectura de Base de Datos Relacional Distribuida ( DRDA ) de IBM y el Lenguaje de Acceso a Datos de Apple Computer . Sin embargo, mucho más comunes eran los sistemas que se ejecutaban completamente en microcomputadoras, incluida una pila de protocolos completa que incluía cualquier soporte de traducción de archivos o redes requerido.

Uno de los primeros ejemplos de un sistema de este tipo fue DataLens de Lotus Development , conocido inicialmente como Blueprint. Blueprint, desarrollado para 1-2-3, admitía una variedad de fuentes de datos, incluidos SQL/DS, DB2, FOCUS y una variedad de sistemas mainframe similares, así como sistemas de microcomputadoras como dBase y los primeros esfuerzos de Microsoft/Ashton-Tate que eventualmente se desarrollarían en Microsoft SQL Server . ^[1] A diferencia del posterior ODBC, Blueprint era un sistema puramente basado en código, que carecía de algo que se aproximara a un lenguaje de comandos como SQL. En su lugar, los programadores usaban estructuras de datos para almacenar la información de la consulta, construyendo una consulta vinculando muchas de estas estructuras entre sí. Lotus se refirió a estas estructuras compuestas como árboles de consulta . ^[2]

Casi al mismo tiempo, un equipo de la industria que incluía a miembros de Sybase (Tom Haggin), Tandem Computers ( Jim Gray y Rao Yendluri) y Microsoft (Kyle Geiger) estaban trabajando en un concepto de SQL dinámico estandarizado. Gran parte del sistema se basaba en el sistema DB-Library de Sybase, con las secciones específicas de Sybase eliminadas y varias adiciones para dar soporte a otras plataformas. ^[3] DB-Library se vio ayudado por un movimiento de toda la industria desde sistemas de bibliotecas que estaban estrechamente vinculados a un lenguaje específico, a sistemas de bibliotecas que eran proporcionados por el sistema operativo y requerían que los lenguajes en esa plataforma se ajustaran a sus estándares. Esto significaba que una sola biblioteca podía usarse con (potencialmente) cualquier lenguaje de programación en una plataforma dada.

El primer borrador de la API de acceso a datos de Microsoft se publicó en abril de 1989, aproximadamente al mismo tiempo que Lotus anunció Blueprint. ^[4] A pesar de la gran ventaja de Blueprint (se estaba ejecutando cuando MSDA todavía era un proyecto en papel), Lotus finalmente se unió a los esfuerzos de MSDA cuando se hizo evidente que SQL se convertiría en el estándar de base de datos de facto. ^[2] Después de una considerable participación de la industria, en el verano de 1989 el estándar se convirtió en SQL Connectivity ( SQLC ). ^[5]

En 1988, varios proveedores, principalmente de las comunidades Unix y de bases de datos, formaron el SQL Access Group (SAG) en un esfuerzo por producir un único estándar básico para el lenguaje SQL. En la primera reunión hubo un debate considerable sobre si el esfuerzo debería o no centrarse únicamente en el lenguaje SQL en sí, o intentar una estandarización más amplia que también incluyera un sistema dinámico de incorporación del lenguaje SQL, lo que llamaron una interfaz de nivel de llamada (CLI). ^[6] Mientras asistía a la reunión con un borrador preliminar de lo que entonces todavía se conocía como MS Data Access, Kyle Geiger de Microsoft invitó a Jeff Balboni y Larry Barnes de Digital Equipment Corporation (DEC) a unirse también a las reuniones de SQLC. SQLC era una posible solución a la convocatoria de la CLI, que estaba siendo liderada por DEC.

El nuevo "grupo de cuatro" de SQLC, MS, Tandem, DEC y Sybase, presentó una versión actualizada de SQLC a la siguiente reunión del SAG en junio de 1990. ^[7] El SAG respondió abriendo el esfuerzo de estándar a cualquier diseño competidor, pero de las muchas propuestas, solo Oracle Corp tenía un sistema que presentaba una competencia seria. Al final, SQLC ganó las votaciones y se convirtió en el borrador del estándar, pero solo después de que se eliminaran grandes porciones de la API: el documento de estándares se redujo de 120 páginas a 50 durante este tiempo. También fue durante este período que se adoptó formalmente el nombre Call Level Interface. ^[7] En 1995, SQL/CLI se convirtió en parte del estándar internacional SQL, ISO/IEC 9075-3. ^[8] El propio SAG fue absorbido por el grupo X/Open en 1996 y, con el tiempo, se convirtió en parte del Common Application Environment de The Open Group .

Microsoft continuó trabajando con el estándar SQLC original, manteniendo muchas de las características avanzadas que se eliminaron de la versión CLI. Estas incluían características como cursores desplazables y consultas de información de metadatos . Los comandos en la API se dividieron en grupos; el grupo Core era idéntico al CLI, las extensiones de Nivel 1 eran comandos que serían fáciles de implementar en controladores, mientras que los comandos de Nivel 2 contenían las características más avanzadas como cursores. Se publicó un estándar propuesto en diciembre de 1991, y se recopilaron las opiniones de la industria y se trabajaron en el sistema hasta 1992, lo que resultó en otro cambio de nombre a ODBC . ^[9]

Durante este tiempo, Microsoft estaba en medio del desarrollo de su sistema de base de datos Jet . Jet combinaba tres subsistemas principales: un motor de base de datos basado en ISAM (también llamado Jet , de manera confusa), una interfaz basada en C que permitía a las aplicaciones acceder a esos datos y una selección de bibliotecas de vínculos dinámicos (DLL) de controladores que permitían que la misma interfaz C redirigiera la entrada y la salida a otras bases de datos basadas en ISAM, como Paradox y xBase . Jet permitía usar un conjunto de llamadas para acceder a bases de datos de microcomputadoras comunes de una manera similar a Blueprint, para entonces rebautizada como DataLens. Sin embargo, Jet no usaba SQL; al igual que DataLens, la interfaz estaba en C y consistía en estructuras de datos y llamadas a funciones.

Los esfuerzos de estandarización de SAG presentaron una oportunidad para que Microsoft adaptara su sistema Jet al nuevo estándar CLI. Esto no sólo convertiría a Windows en una plataforma de primera para el desarrollo CLI, sino que también permitiría a los usuarios utilizar SQL para acceder tanto a Jet como a otras bases de datos. Lo que faltaba era el analizador SQL que pudiera convertir esas llamadas desde su formato de texto a la interfaz C utilizada en Jet. Para resolver esto, MS se asoció con PageAhead Software para utilizar su procesador de consultas existente, SIMBA. SIMBA se utilizó como un analizador por encima de la biblioteca C de Jet, convirtiendo Jet en una base de datos SQL. Y debido a que Jet podía reenviar esas llamadas basadas en C a otras bases de datos, esto también permitió que SIMBA consultara otros sistemas. Microsoft incluyó controladores para Excel para convertir sus documentos de hojas de cálculo en tablas de bases de datos accesibles mediante SQL. ^[10]

ODBC 1.0 se lanzó en septiembre de 1992. ^[11] En ese momento, había poco soporte directo para bases de datos SQL (en comparación con ISAM), y los primeros controladores se destacaron por su bajo rendimiento. Parte de esto era inevitable debido a la ruta que tomaban las llamadas a través de la pila basada en Jet; las llamadas ODBC a bases de datos SQL se convertían primero del dialecto SQL de Simba Technologies al formato interno basado en C de Jet, y luego se pasaban a un controlador para su conversión nuevamente a llamadas SQL para la base de datos. Tanto Digital Equipment como Oracle contrataron a Simba Technologies para desarrollar controladores para sus bases de datos también. ^[12]

Hacia 1993, OpenLink Software lanzó uno de los primeros controladores ODBC de terceros desarrollados independientemente para PROGRESS DBMS , ^[13] y pronto siguió con su SDK UDBC (una API multiplataforma equivalente de ODBC y SAG/CLI) y controladores asociados para PROGRESS , Sybase, Oracle y otros DBMS, para usar en sistemas operativos tipo Unix ( AIX , HP-UX , Solaris , Linux , etc.), VMS , Windows NT , OS/2 y otros sistemas operativos. ^[14]

Mientras tanto, el esfuerzo por crear un estándar CLI se prolongó y no fue hasta marzo de 1995 que se finalizó la versión definitiva. Para entonces, Microsoft ya había otorgado a Visigenic Software una licencia de código fuente para desarrollar ODBC en plataformas distintas de Windows. Visigenic adaptó ODBC al sistema operativo Mac OS clásico y a una amplia variedad de plataformas Unix, donde ODBC se convirtió rápidamente en el estándar de facto. ^[15] Hoy en día, la CLI "real" es poco común. Los dos sistemas siguen siendo similares y muchas aplicaciones se pueden adaptar de ODBC a CLI con pocos o ningún cambio. ^[16]

Con el tiempo, los proveedores de bases de datos se hicieron cargo de las interfaces de los controladores y proporcionaron enlaces directos a sus productos. Saltarse las conversiones intermedias hacia y desde Jet o contenedores similares a menudo resultó en un mayor rendimiento. Sin embargo, para entonces Microsoft había cambiado el enfoque hacia su concepto OLE DB ^{[17] (recientemente restablecido [18]} ), que proporcionaba acceso directo a una variedad más amplia de fuentes de datos, desde libretas de direcciones hasta archivos de texto. Luego siguieron varios sistemas nuevos que desviaron aún más su atención de ODBC, incluidos ActiveX Data Objects (ADO) y ADO.net , que interactuaron más o menos con ODBC durante sus vidas.

A medida que Microsoft dejó de trabajar directamente en ODBC, el campo Unix lo fue adoptando cada vez más. Esto fue impulsado por dos cambios dentro del mercado, la introducción de interfaces gráficas de usuario (GUI) como GNOME que proporcionaron la necesidad de acceder a estas fuentes en forma no textual, y la aparición de sistemas de bases de datos de software abierto como PostgreSQL y MySQL , inicialmente bajo Unix. La posterior adopción de ODBC por parte de Apple para usar el paquete iODBC estándar del lado Unix Mac OS X 10.2 (Jaguar) ^[19] (que OpenLink Software había estado proporcionando de forma independiente para Mac OS X 10.0 e incluso Mac OS 9 desde 2001 ^[20] ) consolidó aún más a ODBC como el estándar para el acceso a datos multiplataforma.

Sun Microsystems utilizó el sistema ODBC como base para su propio estándar abierto, Java Database Connectivity (JDBC). En la mayoría de los aspectos, JDBC puede considerarse una versión de ODBC para el lenguaje de programación Java en lugar de C. Los puentes JDBC a ODBC permiten que los programas basados ​​en Java accedan a fuentes de datos a través de controladores ODBC en plataformas que carecen de un controlador JDBC nativo, aunque estos son relativamente raros en la actualidad. A la inversa, los puentes ODBC a JDBC permiten que los programas basados ​​en C accedan a fuentes de datos a través de controladores JDBC en plataformas o desde bases de datos que carecen de controladores ODBC adecuados.

Hoy en día, ODBC sigue siendo ampliamente utilizado y existen controladores para la mayoría de las plataformas y bases de datos. No es raro encontrar controladores ODBC para motores de bases de datos que están diseñados para ser integrados, como SQLite , como una forma de permitir que las herramientas existentes actúen como interfaces para estos motores para realizar pruebas y depurar errores. ^[21]

• 1.0: lanzado en septiembre de 1992 ^[23]
• 2.0: alrededor de 1994
• 2.5
• 3.0: c. 1995, John Goodson de Intersolv y Frank Pellow y Paul Cotton de IBM aportaron importantes contribuciones a ODBC 3.0 ^[24]
• 3.5: hacia 1997
• 3.8: c. 2009, con Windows 7 ^[25]
• 4.0: Se anunció el desarrollo en junio de 2016 ^[26] con la primera implementación con SQL Server 2017 lanzada en septiembre de 2017 y controladores de escritorio adicionales a fines de 2018. Especificación final en Github

• 1.0 (1993–08): Se utilizó el procesador de consultas SIMBA producido por PageAhead Software.
• 2.0 (1994–12): Se utiliza con ODBC 2.0.
• 3.0 (1995–10): compatible con Windows 95 y Windows NT Workstation o NT Server 3.51. En esta versión sólo se incluyeron controladores de 32 bits.
• 3.5 (1996–10): admite el conjunto de caracteres de doble byte (DBCS) y permite el uso de nombres de fuentes de datos de archivos (DSN). El controlador de Microsoft Access se lanzó en una versión RISC para su uso en plataformas Alpha para Windows 95/98 y Windows NT 3.51 y sistemas operativos posteriores.
• 4.0 (finales de 1998): Compatibilidad con el formato Unicode de Microsoft Jet Engine junto con compatibilidad con el formato ANSI de versiones anteriores.

ODBC se basa en el modelo de controlador de dispositivo , donde el controlador encapsula la lógica necesaria para convertir un conjunto estándar de comandos y funciones en las llamadas específicas requeridas por el sistema subyacente. Por ejemplo, un controlador de impresora presenta un conjunto estándar de comandos de impresión, la API, a las aplicaciones que utilizan el sistema de impresión. Las llamadas realizadas a esas API son convertidas por el controlador al formato utilizado por el hardware real, por ejemplo PostScript o PCL .

En el caso de ODBC, los controladores encapsulan muchas funciones que pueden dividirse en varias categorías amplias. Un conjunto de funciones se ocupa principalmente de buscar, conectarse y desconectarse del DBMS con el que se comunica el controlador. Un segundo conjunto se utiliza para enviar comandos SQL desde el sistema ODBC al DBMS, convirtiendo o interpretando cualquier comando que no sea compatible internamente. Por ejemplo, un DBMS que no admita cursores puede emular esta funcionalidad en el controlador. Finalmente, otro conjunto de comandos, que se utiliza principalmente internamente, se utiliza para convertir datos de los formatos internos del DBMS a un conjunto de formatos ODBC estandarizados, que se basan en los formatos del lenguaje C.

Un controlador ODBC permite que una aplicación compatible con ODBC utilice una fuente de datos , normalmente un DBMS. Existen algunos controladores que no son DBMS, para fuentes de datos como archivos CSV , implementando un pequeño DBMS dentro del propio controlador. Existen controladores ODBC para la mayoría de los DBMS, incluidos Oracle , PostgreSQL , MySQL , Microsoft SQL Server (pero no para la edición Compact, también conocida como CE ), Mimer SQL , Sybase ASE , SAP HANA ^{[28] [29]} e IBM Db2 . Debido a que las diferentes tecnologías tienen diferentes capacidades, la mayoría de los controladores ODBC no implementan toda la funcionalidad definida en el estándar ODBC. Algunos controladores ofrecen funcionalidad adicional no definida por el estándar.

Los controladores de dispositivos normalmente se enumeran, configuran y administran mediante una capa de administrador independiente, que puede proporcionar funciones adicionales. Por ejemplo, los sistemas de impresión suelen incluir funciones para proporcionar cola de impresión además de los controladores, lo que permite la cola de impresión para cualquier impresora compatible.

En ODBC, el Administrador de controladores (DM) proporciona estas características. ^[30] El DM puede enumerar los controladores instalados y presentarlos como una lista, a menudo en un formato basado en GUI.

Pero lo más importante para el funcionamiento del sistema ODBC es el concepto de nombre de fuente de datos (DSN) del DM. Los DSN recopilan información adicional necesaria para conectarse a una fuente de datos específica , en comparación con el propio DBMS. Por ejemplo, el mismo controlador MySQL se puede utilizar para conectarse a cualquier servidor MySQL, pero la información de conexión para conectarse a un servidor privado local es diferente de la información necesaria para conectarse a un servidor público alojado en Internet. El DSN almacena esta información en un formato estandarizado y el DM se la proporciona al controlador durante las solicitudes de conexión. El DM también incluye una funcionalidad para presentar una lista de DSN utilizando nombres legibles para humanos y para seleccionarlos en tiempo de ejecución para conectarse a diferentes recursos.

El DM también incluye la capacidad de guardar DSN parcialmente completos, con código y lógica para solicitar al usuario cualquier información faltante en tiempo de ejecución. Por ejemplo, se puede crear un DSN sin una contraseña requerida. Cuando una aplicación ODBC intenta conectarse al DBMS utilizando este DSN, el sistema hará una pausa y solicitará al usuario que proporcione la contraseña antes de continuar. Esto libera al desarrollador de la aplicación de tener que crear este tipo de código, así como de tener que saber qué preguntas hacer. Todo esto está incluido en el controlador y los DSN.

Un puente es un tipo especial de controlador: un controlador que utiliza otra tecnología basada en controladores.

Un puente ODBC-JDBC consiste en un controlador ODBC que utiliza los servicios de un controlador JDBC para conectarse a una base de datos. Este controlador traduce las llamadas a funciones ODBC en llamadas a métodos JDBC. Los programadores suelen utilizar un puente de este tipo cuando carecen de un controlador ODBC para alguna base de datos pero tienen acceso a un controlador JDBC. Ejemplos: Puente ODBC-JDBC de OpenLink, Puente ODBC-JDBC de SequeLink.

Un puente JDBC-ODBC consiste en un controlador JDBC que emplea un controlador ODBC para conectarse a una base de datos de destino. Este controlador traduce las llamadas a métodos JDBC en llamadas a funciones ODBC. Los programadores suelen utilizar un puente de este tipo cuando una base de datos determinada carece de un controlador JDBC, pero es accesible a través de un controlador ODBC. Sun Microsystems incluyó un puente de este tipo en la JVM , pero lo consideró una medida provisional mientras existían pocos controladores JDBC (el puente JDBC-ODBC integrado se eliminó de la JVM en Java 8 ^[31] ). Sun nunca pensó que su puente fuera para entornos de producción y, en general, recomendó no utilizarlo. A partir de 2008, ^[actualizar]los proveedores independientes de acceso a datos ofrecen puentes JDBC-ODBC que admiten los estándares actuales para ambos mecanismos y que superan con creces al integrado de la JVM. ^{[ cita requerida ]} Ejemplos: Puente JDBC-ODBC de OpenLink, Puente JDBC-ODBC de SequeLink, Puente JDBC-ODBC de ZappySys.

Un puente OLE DB-ODBC consiste en un proveedor OLE DB que utiliza los servicios de un controlador ODBC para conectarse a una base de datos de destino. Este proveedor traduce las llamadas a métodos OLE DB en llamadas a funciones ODBC. Los programadores suelen utilizar un puente de este tipo cuando una base de datos determinada carece de un proveedor OLE DB, pero es accesible a través de un controlador ODBC. Microsoft incluye uno, MSDASQL.DLL, como parte del paquete de componentes del sistema MDAC , junto con otros controladores de bases de datos, para simplificar el desarrollo en lenguajes compatibles con COM (por ejemplo, Visual Basic ). Otros fabricantes también han desarrollado uno, en particular OpenLink Software, cuyo proveedor OLE DB de 64 bits para orígenes de datos ODBC llenó el vacío cuando Microsoft inicialmente desaprobó este puente para su sistema operativo de 64 bits. ^[32] (Más tarde, Microsoft cedió y los sistemas operativos Windows de 64 bits a partir de Windows Server 2008 y Windows Vista SP1 se entregaron con una versión de 64 bits de MSDASQL). Ejemplos: OpenLink OLEDB-ODBC Bridge Archivado el 27 de marzo de 2017 en Wayback Machine , SequeLink OLEDB-ODBC Bridge.

Un puente ADO.NET-ODBC consiste en un proveedor ADO.NET que utiliza los servicios de un controlador ODBC para conectarse a una base de datos de destino. Este proveedor traduce las llamadas a métodos ADO.NET en llamadas a funciones ODBC. Los programadores suelen utilizar un puente de este tipo cuando una base de datos determinada carece de un proveedor ADO.NET, pero es accesible a través de un controlador ODBC. Microsoft incluye uno como parte del paquete de componentes del sistema MDAC , junto con otros controladores de bases de datos, para simplificar el desarrollo en C# . Otros terceros también han desarrollado uno de estos. Ejemplos: Puente ADO.NET-ODBC de OpenLink, Puente ADO.NET-ODBC de SequeLink.

• Acceso a datos GNU
• Conectividad de base de datos Java (JDBC)
• Arquitectura de servicios abiertos de Windows
• Administrador de ODBC

Bibliografía

Citas

• Descripción general de Microsoft ODBC
• Administración ODBC de IBM i
• Diapositivas de la presentación de www.roth.net
• Artículo sobre el historial de las API de acceso a datos y ODBC de Microsoft.
• Página de Github: Especificación ODBC 4.0 de Microsoft