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 intentaron hacerlo independiente de los sistemas de bases de datos y sistemas operativos . [ cita necesaria ] Una aplicación escrita con ODBC se puede portar a otras plataformas, tanto en el lado del cliente como del servidor, con pocos cambios en el código de acceso a los datos.
ODBC logra la independencia del 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. Se puede considerar que un controlador ODBC es análogo a un controlador de impresora u otro controlador, ya que proporciona un conjunto estándar de funciones para que las utilice la aplicación e implementa una funcionalidad específica 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 DBMS principales, muchas otras fuentes de datos como sistemas de libreta 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 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 Unix y mainframe . ODBC conservó varias funciones que se eliminaron como parte del esfuerzo de CLI. Posteriormente, ODBC completo se transfirió 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 transferir de una plataforma a otra con pocos cambios.
La introducción de la base de datos relacional basada en mainframe durante la década de 1970 condujo a una proliferación de métodos de acceso a datos. Generalmente, estos sistemas operaban junto con un procesador de comandos simple que permitía a los usuarios escribir comandos similares al 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 aquellas que lo hicieron utilizaron una amplia variedad de metodologías. La introducción de SQL tenía 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 rudimentarias , los usuarios a menudo querían usar SQL dentro de un programa escrito en otro lenguaje, por ejemplo Fortran o C. Esto llevó al concepto de SQL integrado , que permitía incrustar código SQL en otro lenguaje. Por ejemplo, una declaración SQL como esta podría insertarse como texto dentro del código fuente C y, durante la compilación , se convertiría a 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 por las declaraciones se interpretarían nuevamente en formatos de datos C, como si se usara un código de biblioteca similar.SELECT * FROM citychar *
Hubo varios problemas con el enfoque de SQL incorporado. Al igual que las diferentes variedades de SQL, los SQL integrados que los utilizaban variaban ampliamente, no sólo de una plataforma a otra, sino incluso entre los distintos idiomas de una misma plataforma: un sistema que permitiera realizar llamadas a IBM Db2 sería muy diferente de uno que realizara llamadas a su propio sistema. SQL/DS . [ dudoso ] Otro problema clave del concepto de SQL incorporado era que el código SQL sólo podía cambiarse en el código fuente del programa, de modo que incluso los cambios más pequeños en la consulta requerían un esfuerzo considerable del programador para modificarlos. El mercado de SQL se refería a esto como SQL estático , versus SQL dinámico que podía cambiarse en cualquier momento, como las interfaces de línea de comandos que se entregaban 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 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 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 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, ni siquiera con diferentes bases de datos en el mismo motor. En efecto, todos esos sistemas eran estáticos, lo que presentaba problemas considerables.
A mediados de la década de 1980, la rápida mejora de las microcomputadoras, y especialmente la introducción de la interfaz gráfica de usuario y programas de aplicaciones ricos en datos como Lotus 1-2-3 , llevaron a un interés creciente en el uso de computadoras personales como plataforma preferida del lado del cliente. en informática cliente-servidor . Según este modelo, grandes mainframes y minicomputadoras se usarí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 necesario un estándar de acceso a datos: en el campo de la computadora central era muy probable que todas las computadoras de una tienda fueran de un solo proveedor y los clientes fueran terminales de computadora que hablaban directamente con ellos, pero en el campo micro No existía tal estandarización y cualquier cliente podía acceder a cualquier servidor utilizando cualquier sistema de red.
A finales 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 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 llamada por otros programas de mainframe 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, eran mucho más comunes los sistemas que se ejecutaban completamente en microcomputadoras, incluida una pila de protocolos completa que incluía cualquier soporte de red o traducción de archivos necesario.
Uno de los primeros ejemplos de un sistema de este tipo fue DataLens de Lotus Development , inicialmente conocido como Blueprint. Blueprint, desarrollado para 1-2-3, soportaba una variedad de fuentes de datos, incluyendo 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 convertiría en Microsoft SQL Server . [1] 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 . [2]
Casi al mismo tiempo, un equipo de la industria que incluí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 basó en el sistema DB-Library de Sybase, con las secciones específicas de Sybase eliminadas y varias adiciones para admitir otras plataformas. [3] DB-Library se vio favorecida por un movimiento en toda la industria desde sistemas de biblioteca que estaban estrechamente vinculados a un lenguaje específico, a sistemas de biblioteca proporcionados por el sistema operativo y que requerían que los lenguajes de esa plataforma se ajustaran a sus estándares. Esto significaba que se podía utilizar una única biblioteca 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, aproximadamente al mismo tiempo que el anuncio de Blueprint por parte de Lotus. [4] A pesar del gran liderazgo de Blueprint (estaba funcionando 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 base de datos de facto. [2] Después de un considerable aporte de la industria, en el verano de 1989 el estándar se convirtió en Conectividad SQL ( SQLC ). [5]
En 1988, varios proveedores, en su mayoría de las comunidades Unix y de bases de datos, formaron el 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 del lenguaje SQL, lo que llamaron una interfaz de nivel de llamada (CLI). . [6] Mientras asistía a la reunión con un borrador inicial 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 CLI, que estaba dirigida por DEC.
El nuevo "grupo de cuatro" de SQLC, MS, Tandem, DEC y Sybase, trajeron una versión actualizada de SQLC a la siguiente reunión del SAG en junio de 1990. [7] El SAG respondió abriendo el esfuerzo estándar a cualquier diseño competidor, pero por supuesto Entre las muchas propuestas, sólo 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 de Interfaz de Nivel de Llamada. [7] En 1995, SQL/CLI pasó a formar parte del estándar internacional SQL, ISO/IEC 9075-3. [8] El grupo X/Open se hizo cargo del propio SAG en 1996 y, con el tiempo, pasó a formar parte del entorno de aplicaciones común de The Open Group .
MS continuó trabajando con el estándar SQLC original, conservando muchas de las funciones avanzadas que se eliminaron de la versión CLI. Estas 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 a la 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 funciones más avanzadas como cursores. En diciembre de 1991 se publicó una propuesta de estándar y se recopilaron aportaciones de la industria que se incorporaron al sistema durante 1992, lo que dio lugar a otro cambio de nombre a ODBC . [9]
Durante este tiempo, Microsoft estaba desarrollando su sistema de base de datos Jet . Jet combinó 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 permite a las aplicaciones acceder a esos datos y una selección de bibliotecas de vínculos dinámicos (DLL) de controladores que permitían a la misma interfaz C redirigir la entrada y la salida a otras bases de datos basadas en ISAM, como Paradox y xBase . Jet permitió el uso de un conjunto de llamadas para acceder a bases de datos de microcomputadoras comunes de una manera similar a Blueprint, que luego pasó a llamarse DataLens. Sin embargo, Jet no utilizó SQL; Al igual que DataLens, la interfaz estaba en C y constaba de 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 líder para el desarrollo de 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 de 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 analizador encima de la biblioteca C de Jet, convirtiendo a Jet en una base de datos SQL. Y como Jet podía reenviar esas llamadas basadas en C a otras bases de datos, esto también permitía a SIMBA consultar otros sistemas. Microsoft incluyó controladores para que Excel convirtiera sus documentos de hoja de cálculo en tablas de bases de datos accesibles en 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 (a diferencia de ISAM), y los primeros controladores se caracterizaban por su bajo rendimiento. Parte de esto era 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 primero se convirtieron del dialecto SQL de Simba Technologies al formato interno basado en C de Jet, luego se pasaron a un controlador para su conversión nuevamente 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. [12]
Alrededor de 1993, OpenLink Software envió uno de los primeros controladores ODBC de terceros desarrollados de forma independiente, para PROGRESS DBMS , [13] y pronto siguió con su SDK UDBC (una API multiplataforma equivalente a ODBC y SAG/CLI) y asociados. controladores 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 del 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 a Windows. Visigenic portó ODBC al Mac OS clásico y a una amplia variedad de plataformas Unix, donde ODBC rápidamente se convirtió en el estándar de facto. [15] La CLI "real" es rara 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. [dieciséis]
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 empacadoras similares a menudo resultó en un mayor rendimiento. Sin embargo, para entonces Microsoft había cambiado de 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. 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 a lo largo de su vida.
A medida que Microsoft desvió su atención del trabajo directo con ODBC, el campo Unix lo adoptó 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 proporcionó 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 utilizar 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 casos, 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 ahora son relativamente raros. 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.
ODBC sigue siendo de uso generalizado en la actualidad, con controladores disponibles 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 destinados a integrarse, como SQLite , como una forma de permitir que las herramientas existentes actúen como interfaces de estos motores para realizar pruebas y depurar. [21]
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 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 admite cursores puede emular esta funcionalidad en el controlador. Finalmente, otro conjunto de comandos, utilizados 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 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.
Los controladores de dispositivos normalmente son enumerados, configurados y administrados por una capa de Administrador separada, que puede proporcionar funcionalidad adicional. Por ejemplo, los sistemas de impresión a menudo incluyen funciones para proporcionar funciones de cola de impresión además de los controladores, lo que proporciona cola de impresión para cualquier impresora compatible.
En ODBC, el Administrador de controladores (DM) proporciona estas funciones. [30] El DM puede enumerar los controladores instalados y presentarlos como una lista, a menudo en forma basada en GUI.
Pero lo más importante para el funcionamiento del sistema ODBC es el concepto del DM de 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 propio DBMS. Por ejemplo, se puede utilizar 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 la proporciona al conductor durante las solicitudes de conexión. El DM también incluye funcionalidad para presentar una lista de DSN utilizando nombres legibles por humanos y 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 necesidad de contraseña. Cuando una aplicación ODBC intenta conectarse al DBMS usando 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 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 consta de un controlador ODBC que utiliza los servicios de un controlador JDBC para conectarse a una base de datos. Este controlador traduce llamadas a funciones ODBC en llamadas a métodos JDBC. Los programadores suelen utilizar este tipo de puente 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.
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 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 se puede acceder a ella a través de un controlador ODBC. Sun Microsystems incluyó uno de esos puentes en la JVM , pero lo vio como una medida provisional mientras existían pocos controladores JDBC (el puente JDBC-ODBC incorporado se eliminó de la JVM en Java 8 [31] ). Sun nunca diseñó su puente 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 el rendimiento de la JVM integrada. [ cita necesaria ] Ejemplos: Puente OpenLink JDBC-ODBC, Puente SequeLink JDBC-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 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 se puede acceder a ella 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 ). Terceros también los han desarrollado, en particular el software 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. [32] (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: Puente OpenLink OLEDB-ODBC, Puente SequeLink OLEDB-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 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 se puede acceder a ella 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# . Terceros también los han desarrollado. Ejemplos: Puente OpenLink ADO.NET-ODBC, Puente SequeLink ADO.NET-ODBC.
Los primeros controladores ODBC […] utilizaban el procesador de consultas SIMBA, que traducía las llamadas en llamadas Microsoft Jet ISAM y enviaba las llamadas al controlador ISAM apropiado para acceder al backend […]
ODBC 1.0 se lanzó en septiembre de 1992
Windows 7 incluye una versión actualizada de ODBC, ODBC 3.8.
Después de más de 15 años desde el último lanzamiento, Microsoft está considerando actualizar la especificación Open Data Base Connectivity (ODBC).