Conectividad de base de datos abierta - Open Database Connectivity

En informática , Open Database Connectivity ( ODBC ) es una interfaz de programación de aplicaciones (API) estándar para acceder a los sistemas de gestión de bases de datos (DBMS). Los diseñadores de ODBC pretendían independizarlo de los sistemas operativos y de bases de datos . Una aplicación escrita con ODBC se puede migrar 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 de DBMS mediante el uso de 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, proporcionando un conjunto estándar de funciones para que las utilice la aplicación e implementando funciones específicas de 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 principales DBMS, muchas otras fuentes de datos como sistemas de libretas de direcciones y Microsoft Excel , e incluso para archivos de texto o valores separados por comas (CSV).

ODBC fue desarrollado originalmente por Microsoft y Simba Technologies a principios de la década de 1990, 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 retuvo varias funciones que se eliminaron como parte del esfuerzo de CLI. Más tarde, ODBC completo se trasladó de nuevo a esas plataformas y se convirtió en un estándar de facto considerablemente más conocido que CLI. La CLI sigue siendo similar a ODBC y las aplicaciones se pueden migrar de una plataforma a otra con pocos cambios.

Historia

Antes de ODBC

La introducción de la base de datos relacional basada en mainframe durante la década de 1970 llevó a una proliferación de métodos de acceso a datos. Por lo general, estos sistemas funcionaban junto con un procesador de comandos simple que permitía a los usuarios escribir comandos en inglés y recibir resultados. Los ejemplos más conocidos son SQL de IBM y QUEL del proyecto Ingres . Estos sistemas pueden o no permitir que otras aplicaciones accedan a los datos directamente, y aquellas que sí 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 sólo tenía características de programación rudimentarios, los usuarios a menudo querido utilizar SQL dentro de un programa escrito en otro idioma, por ejemplo Fortran o C . Esto llevó al concepto de Embedded SQL , que permitió que el código SQL se incrustara en otro idioma. Por ejemplo, una declaración SQL como SELECT * FROM citypodría insertarse como texto dentro del código fuente de C, y durante la compilación se convertiría en un formato personalizado que llamara directamente a una función dentro de una biblioteca que pasaría la declaración al sistema SQL. Los resultados devueltos de las declaraciones se volverían a interpretar en formatos de datos C, como char *usar un código de biblioteca similar.

Hubo varios problemas con el enfoque de SQL incorporado. Al igual que las diferentes variedades de SQL, los LSQ Embedded que los empleados varían ampliamente, no sólo desde una plataforma a otra, pero incluso a través de idiomas en una sola plataforma - un sistema que permite llamadas en IBM 's de DB2 se vería muy diferente de aquella que pone en su propio SQL / DS . Otro problema clave del concepto de SQL incrustado era que el código SQL solo se podía cambiar en el código fuente del programa, por lo que incluso los pequeños cambios en la consulta requerían un considerable esfuerzo de modificación por parte del programador. El mercado de SQL se refirió a esto como SQL estático , versus SQL dinámico que podría cambiarse en cualquier momento, como las interfaces de línea de comandos que se incluyen con casi todos los sistemas SQL, o una interfaz de programación que dejaba el SQL como texto sin formato hasta que se llamaba. . Los sistemas de SQL dinámico se convirtieron en un foco importante para los proveedores de SQL durante la década de 1980.

Las bases de datos de mainframe más antiguas y los sistemas basados ​​en microcomputadoras más recientes que se basaban en ellas, generalmente no tenían un procesador de comandos similar a SQL entre el usuario y el motor de la base de datos. En cambio, el programa accedía directamente a los datos: una biblioteca de programación en el caso de grandes sistemas de mainframe, o una interfaz de línea de comandos o un sistema de formularios interactivos en el caso de dBASE y aplicaciones similares. Por lo general, otros programas que se ejecutan en la máquina no pueden acceder directamente a los datos de dBASE. A esos programas se les puede dar una forma de acceder a estos datos, a menudo a través de bibliotecas, pero no funcionaría con ningún otro motor de base de datos, o incluso con diferentes bases de datos en el mismo motor. En efecto, todos estos sistemas eran estáticos, lo que presentaba problemas considerables.

Esfuerzos iniciales

A mediados de la década de 1980, la rápida mejora en las microcomputadoras, y especialmente la introducción de la interfaz gráfica de usuario y los programas de aplicaciones ricos en datos como Lotus 1-2-3, llevaron a un creciente interés en el uso de computadoras personales como la plataforma preferida del lado del cliente. en informática cliente-servidor . Bajo este modelo, los grandes mainframes y minicomputadoras se utilizarían principalmente para enviar datos a través de redes de área local a microcomputadoras que interpretarían, mostrarían y manipularían esos datos. Para que este modelo funcionara, era un requisito un estándar de acceso a datos: en el campo de mainframe era muy probable que todas las computadoras en una tienda fueran de un solo proveedor y los clientes fueran terminales de computadora que hablaran directamente con ellos, pero en el campo micro no existe No existía tal estandarización y cualquier cliente podía acceder a cualquier servidor utilizando cualquier sistema de red.

A fines de la década de 1980, se estaban realizando varios esfuerzos para proporcionar una capa de abstracción para este propósito. Algunos de estos estaban relacionados con el mainframe, diseñados para permitir que los programas que se ejecutan en esas máquinas se traduzcan entre la variedad de SQL y proporcionen una única interfaz común que luego podría ser invocada por otros programas de mainframe o microcomputadoras. Estas soluciones incluyen Distributed Relational Database de IBM Architecture ( DRDA ) y Apple Computer 's de acceso a datos Lenguaje . 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 de red requerido.

Uno de los primeros ejemplos de un sistema tal fue Lotus Development 's DataLens , inicialmente conocido 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 de mainframe similares, así como sistemas de microcomputadoras como dBase y los primeros esfuerzos de Microsoft / Ashton-Tate que eventualmente se convertiría en Microsoft SQL Server . A diferencia del ODBC posterior, Blueprint era un sistema puramente basado en código, sin nada que se aproximara a un lenguaje de comandos como SQL. En cambio, los programadores utilizaron estructuras de datos para almacenar la información de la consulta, construyendo una consulta vinculando muchas de estas estructuras. Lotus se refirió a estas estructuras compuestas como árboles de consulta .

Casi al mismo tiempo, un equipo de la industria que incluía a miembros de Sybase (Tom Haggin), Tandem Computers ( Jim Gray & Rao Yendluri) y Microsoft (Kyle G) estaban trabajando en un concepto de SQL dinámico estandarizado. Gran parte del sistema se basó en el sistema DB-Library de Sybase, con las secciones específicas de Sybase eliminadas y varias adiciones para admitir otras plataformas. DB-Library se benefició de un cambio en toda la industria de los sistemas de bibliotecas que estaban estrechamente vinculados a un idioma específico, a los sistemas de bibliotecas que proporcionaba el sistema operativo y requerían que los idiomas de esa plataforma se ajustaran a sus estándares. Esto significaba que una sola biblioteca podría usarse con (potencialmente) cualquier lenguaje de programación en una plataforma determinada.

El primer borrador de la API de acceso a datos de Microsoft se publicó en abril de 1989, casi al mismo tiempo que el anuncio de Blueprint de Lotus. 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 quedó claro que SQL se convertiría en el estándar de facto de la base de datos. Después de una considerable contribución de la industria, en el verano de 1989 el estándar se convirtió en SQL Connectivity ( SQLC ).

SAG y CLI

En 1988, varios proveedores, en su mayoría de las comunidades de bases de datos y Unix , formaron SQL Access Group (SAG) en un esfuerzo por producir un estándar básico único para el lenguaje SQL. En la primera reunión hubo un debate considerable sobre si el esfuerzo debería funcionar únicamente en el lenguaje SQL en sí, o intentar una estandarización más amplia que incluyera también un sistema dinámico de integración de lenguaje SQL, lo que llamaron una interfaz de nivel de llamada (CLI) . Mientras asistía a la reunión con un borrador inicial de lo que 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 solución potencial a la llamada de CLI, que estaba siendo dirigida por DEC.

El nuevo "grupo de cuatro" de SQLC, MS, Tandem, DEC y Sybase, trajo una versión actualizada de SQLC a la próxima reunión del SAG en junio de 1990. El SAG respondió abriendo el esfuerzo 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ó los votos y se convirtió en el borrador del estándar, pero solo después de que se eliminaron 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 Interfaz de nivel de llamada. En 1995, SQL / CLI se convirtió en parte del estándar internacional SQL, ISO / IEC 9075-3. El SAG misma fue asumida por la X / Open grupo en 1996, y, con el tiempo, se convirtió en parte de The Open Group 's Entorno de aplicación común .

MS continuó trabajando con el estándar SQLC original, conservando muchas de las características avanzadas que se eliminaron de la versión CLI. Estos incluían funciones como cursores desplazables y consultas de información de metadatos . Los comandos de 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 los controladores, mientras que los comandos de Nivel 2 contenían las características más avanzadas como cursores. Una norma propuesta fue lanzada en diciembre de 1991, y la información de la industria se recopiló y trabajó en el sistema hasta 1992, lo que resultó en otro cambio de nombre a ODBC .

JET y ODBC

Durante este tiempo, Microsoft estaba desarrollando su sistema de base de datos Jet . Jet combinó tres subsistemas primarios; un motor de base de datos basado en ISAM (también llamado Jet , de manera confusa), una interfaz basada en C que permite que las aplicaciones accedan a esos datos y una selección de bibliotecas de enlace dinámico (DLL) del controlador que permiten que la misma interfaz C redirija la entrada y la salida a otras bases de datos basadas en ISAM, como Paradox y xBase . Jet permitió usar un conjunto de llamadas para acceder a bases de datos comunes de microcomputadoras de una manera similar a Blueprint, que en ese momento cambió su nombre a DataLens. Sin embargo, Jet no usó SQL; como 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 solo convertiría a Windows en una plataforma principal para el desarrollo de CLI, sino que también permitiría a los usuarios usar SQL para acceder tanto a Jet como a otras bases de datos. Lo que faltaba era el analizador SQL que podía convertir esas llamadas de su forma de texto a la interfaz C utilizada en Jet. Para resolver esto, MS se asoció con PageAhead Software para usar su procesador de consultas existente, SIMBA. SIMBA se utilizó como analizador sobre 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ó a SIMBA consultar otros sistemas. Microsoft incluyó controladores para Excel para convertir sus documentos de hoja de cálculo en tablas de base de datos accesibles a SQL.

Lanzamiento y desarrollo continuo

ODBC 1.0 se lanzó en septiembre de 1992. En ese momento, había poco soporte directo para las bases de datos SQL (frente a ISAM), y se observó que los primeros controladores tenían un rendimiento deficiente. Algo de esto fue inevitable debido a la ruta que tomaron las llamadas a través de la pila basada en Jet; Las llamadas ODBC a bases de datos SQL se convirtieron primero del dialecto SQL de Simba Technologies al formato interno basado en C de Jet, y luego se pasaron a un controlador para volver a convertirlas en llamadas SQL para la base de datos. Digital Equipment y Oracle también contrataron a Simba Technologies para desarrollar controladores para sus bases de datos.

Alrededor de 1993, OpenLink Software envió uno de los primeros controladores ODBC de terceros desarrollados de forma independiente, para PROGRESS DBMS , y pronto siguió con su SDK UDBC (una API multiplataforma equivalente a ODBC y SAG / CLI) y controladores asociados para PROGRESS , Sybase, Oracle y otros DBMS, para su uso en sistemas operativos similares a Unix ( AIX , HP-UX , Solaris , Linux , etc.), VMS , Windows NT , OS / 2 y otros sistemas operativos.

Mientras tanto, el esfuerzo estándar de 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 portó ODBC a Mac OS y una amplia variedad de plataformas Unix, donde ODBC se convirtió rápidamente en el estándar de facto. La CLI "real" es poco común hoy en día. Los dos sistemas siguen siendo similares y muchas aplicaciones se pueden migrar de ODBC a CLI con pocos o ningún cambio.

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. Omitir las conversiones intermedias desde y hacia Jet o envolturas similares a menudo resultaba en un mayor rendimiento. Sin embargo, para entonces, Microsoft había cambiado de enfoque a su concepto OLE DB (recientemente restablecido), que brindaba acceso directo a una variedad más amplia de fuentes de datos, desde libretas de direcciones hasta archivos de texto. 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 su vida útil.

A medida que Microsoft desvió su atención de trabajar directamente en ODBC, el campo de Unix lo estaba adoptando cada vez más. Esto fue impulsado por dos cambios en el mercado, la introducción de interfaces gráficas de usuario (GUI) como GNOME que proporcionaban 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 Apple para usar el paquete estándar iODBC del lado de Unix Mac OS X 10.2 (Jaguar) (que OpenLink Software había estado proporcionando de forma independiente para Mac OS X 10.0 e incluso Mac OS 9 desde 2001) 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 formas, JDBC se puede considerar 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 las fuentes de datos a través de controladores ODBC en plataformas que carecen de un controlador JDBC nativo, aunque ahora son relativamente raros. A la inversa, los puentes de ODBC a JDBC permiten que los programas basados ​​en C accedan a las fuentes de datos a través de controladores JDBC en plataformas o desde bases de datos que carecen de controladores ODBC adecuados.

ODBC hoy

ODBC sigue siendo de amplio uso en la actualidad, con controladores disponibles para la mayoría de las plataformas y la mayoría de las bases de datos. No es raro encontrar controladores ODBC para motores de base de datos que están destinados a estar integrados, como SQLite , como una forma de permitir que las herramientas existentes actúen como interfaces de estos motores para probar y depurar.

Sin embargo, el auge de la informática de cliente ligero que utiliza HTML como formato intermedio ha reducido la necesidad de ODBC. Muchas plataformas de desarrollo web contienen enlaces directos a bases de datos de destino, siendo MySQL muy común. En estos escenarios, no hay acceso directo del lado del cliente ni múltiples sistemas de software de cliente para soportar; todo pasa por la aplicación HTML proporcionada por el programador. La virtualización que ofrece ODBC ya no es un requisito importante y el desarrollo de ODBC ya no es tan activo como antes. Pero si bien ODBC ya no es un requisito importante para la programación cliente-servidor, ahora es más importante para el acceso, la virtualización y la integración en escenarios de análisis y ciencia de datos. Estos nuevos requisitos se reflejan en las nuevas características de ODBC 4.0, como datos semiestructurados y jerárquicos, autenticación web y mejora del rendimiento.

Historial de versiones

Historial de versiones:

  • 1.0: lanzado en septiembre de 1992
  • 2.0: c. 1994
  • 2.5
  • 3.0: c. 1995, John Goodson de Intersolv y Frank Pellow y Paul Cotton de IBM proporcionaron una contribución significativa a ODBC 3.0
  • 3,5: c. 1997
  • 3.8: c. 2009, con Windows 7
  • 4.0: Desarrollo anunciado en junio de 2016 con la primera implementación con SQL Server 2017 lanzada en septiembre de 2017 y controladores de escritorio adicionales a finales de 2018 especificaciones finales en Github

Conductores y gerentes

Conductores

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. El controlador convierte las llamadas realizadas a esas API al formato utilizado por el hardware real, por ejemplo, PostScript o PCL .

En el caso de ODBC, los controladores encapsulan muchas funciones que se pueden dividir en varias categorías amplias. Un conjunto de funciones se ocupa principalmente de encontrar, conectarse y desconectarse del DBMS con el que habla 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 utilizan principalmente de forma interna, 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 , mediante la implementación de un pequeño DBMS dentro del propio controlador. Existen controladores ODBC para la mayoría de DBMS, incluidos Oracle , PostgreSQL , MySQL , Microsoft SQL Server (pero no para la edición Compact también conocida como CE ), Sybase ASE , SAP HANA y DB2 . Debido a que las diferentes tecnologías tienen diferentes capacidades, la mayoría de los controladores ODBC no implementan todas las funciones definidas en el estándar ODBC. Algunos controladores ofrecen funciones adicionales no definidas por el estándar.

Administrador de conductores

Los controladores de dispositivos normalmente se enumeran, configuran y administran mediante una capa de administrador separada, que puede proporcionar funcionalidad adicional. Por ejemplo, los sistemas de impresión a menudo incluyen una funcionalidad para proporcionar una función de puesta en cola sobre los controladores, proporcionando una puesta en cola de impresión para cualquier impresora compatible.

En ODBC, Driver Manager (DM) proporciona estas características. El DM puede enumerar los controladores instalados y presentarlos como una lista, a menudo en una forma basada en GUI.

Pero más importante para el funcionamiento del sistema ODBC es el concepto de DM de un nombre de fuente de datos (DSN). Los DSN recopilan información adicional necesaria para conectarse a una fuente de datos específica , en comparación con el DBMS en sí. Por ejemplo, se puede usar el mismo controlador MySQL 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 lo proporciona al controlador durante las solicitudes de conexión. El DM también incluye funcionalidad para presentar una lista de DSN utilizando nombres legibles por 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 que falte 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 se detendrá y le pedirá 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, además de tener que saber qué preguntas hacer. Todo esto está incluido en el controlador y los DSN.

Configuraciones puente

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

Puentes de ODBC a JDBC (ODBC-JDBC)

Un puente ODBC-JDBC consta de 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 OpenLink ODBC-JDBC , Puente SequeLink ODBC-JDBC .

Puentes JDBC a ODBC (JDBC-ODBC)

Un puente JDBC-ODBC consta de 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ó uno de estos puentes en la JVM , pero lo vio como una medida provisional mientras existían pocos controladores JDBC (el puente JDBC-ODBC integrado se eliminó de la JVM en Java 8). Sun nunca diseñó su puente para entornos de producción y, en general, recomendó no usarlo. A partir de 2008, 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 a la JVM incorporada. Ejemplos: Puente OpenLink JDBC-ODBC , Puente SequeLink JDBC-ODBC .

Puentes OLE DB a ODBC

Un puente OLE DB-ODBC consta de 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 al método 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 envía 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 ). Los terceros también han desarrollado este tipo de software, en particular OpenLink, cuyo proveedor OLE DB de 64 bits para fuentes de datos ODBC llenó el vacío cuando Microsoft inicialmente desaprobó este puente para su sistema operativo de 64 bits. (Microsoft cedió más tarde, y Windows de 64 bits a partir de Windows Server 2008 y Windows Vista SP1 se envió con una versión de 64 bits de MSDASQL). Ejemplos: OpenLink OLEDB-ODBC Bridge , SequeLink OLEDB-ODBC Bridge .

Puentes de ADO.NET a ODBC

Un puente ADO.NET-ODBC consta de 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 al método 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 envía uno como parte del paquete de componentes del sistema MDAC , junto con otros controladores de base de datos, para simplificar el desarrollo en C # . Los terceros también han desarrollado tales. Ejemplos: OpenLink ADO.NET-ODBC Bridge , SequeLink ADO.NET-ODBC Bridge .

Ver también

Referencias

Bibliografía
  • Geiger, Kyle (1995). Dentro de ODBC . Microsoft Press. ISBN 9781556158155.
Citas

enlaces externos