Edit filter log

'Shravan is '''Open Database Connectivity''' ('''ODBC''') is a standard [[application programming interface]] (API) for accessing [[database management system]]s (DBMS). The designers of ODBC aimed to make it independent of database systems and [[operating system]]s. An application written using ODBC can be ported to other platforms, both on the client and server side, with few changes to the data access code. ODBC accomplishes DBMS independence by using an ''ODBC driver'' as a translation layer between the application and the DBMS. The application uses ODBC functions through an ''ODBC driver manager'' with which it is linked, and the driver passes the [[Query language|query]] to the DBMS. An ODBC driver can be thought of as analogous to a printer driver or other driver, providing a standard set of functions for the application to use, and implementing DBMS-specific functionality. An application that can use ODBC is referred to as "ODBC-compliant". Any ODBC-compliant application can access any DBMS for which a driver is installed. Drivers exist for all major DBMSs, many other data sources like [[address book]] systems and [[Microsoft Excel]], and even for text or [[comma-separated values]] (CSV) files. ODBC was originally developed by [[Microsoft]] and [https://www.progress.com/odbc Progress DataDirect] during the early 1990s, and became the basis for the [[Call Level Interface]] (CLI) standardized by [[SQL Access Group]] in the [[Unix]] and [[Mainframe computer|mainframe]] field. ODBC retained several features that were removed as part of the CLI effort. Full ODBC was later ported back to those platforms, and became a [[de facto standard]] considerably better known than CLI. The CLI remains similar to ODBC, and applications can be ported from one platform to the other with few changes.so it is useful. ==History== ===Before ODBC=== The introduction of the [[Mainframe computer|mainframe]]-based [[relational database]] during the 1970s led to a proliferation of data access methods. Generally these systems operated together with a simple command processor that allowed users to type in English-like commands, and receive output. The best-known examples are [[SQL]] from [[IBM]] and [[QUEL query languages|QUEL]] from the [[Ingres (database)|Ingres]] project. These systems may or may not allow other applications to access the data directly, and those that did used a wide variety of methodologies. The introduction of [[SQL]] aimed to solve the problem of ''language'' standardization, although substantial differences in implementation remained. Also, since the SQL language had only rudimentary programming features, users often wanted to use SQL within a program written in another language, say [[Fortran]] or [[C (programming language)|C]]. This led to the concept of [[Embedded SQL]], which allowed SQL code to be ''embedded'' within another language. For instance, a SQL statement like <code>SELECT * FROM city</code> could be inserted as text within C source code, and during [[compiler|compiling]] it would be converted into a custom format that directly called a function within a [[Library (computing)|library]] that would pass the statement into the SQL system. Results returned from the statements would be interpreted back into C data formats like <code>char *</code> using similar library code. There were several problems with the Embedded SQL approach. Like the different varieties of SQL, the Embedded SQLs that used them varied widely, not only from platform to platform, but even across languages on one platform – a system that allowed calls into [[IBM]]'s [[IBM DB2|DB2]] would look very different from one that called into their own [[IBM SQL/DS|SQL/DS]].{{Dubious|Before-ODBC section|reason=different, how?|date=February 2013}} Another key problem to the Embedded SQL concept was that the SQL code could only be changed in the program's source code, so that even small changes to the query required considerable programmer effort to modify. The SQL market referred to this as ''static SQL'', versus ''dynamic SQL'' which could be changed at any time, like the [[command-line interface]]s that shipped with almost all SQL systems, or a programming interface that left the SQL as plain text until it was called. Dynamic SQL systems became a major focus for SQL vendors during the 1980s. Older mainframe databases, and the newer [[microcomputer]] based systems that were based on them, generally did not have a SQL-like command processor between the user and the database engine. Instead, the data was accessed directly by the program – a programming library in the case of large mainframe systems, or a [[command line interface]] or interactive forms system in the case of [[dBASE]] and similar applications. Data from dBASE could not generally be accessed directly by other programs running on the machine. Those programs may be given a way to access this data, often through libraries, but it would not work with any other database engine, or even different databases in the same engine. In effect, all such systems were static, which presented considerable problems. ===Early efforts=== By the mid-1980s the rapid improvement in microcomputers, and especially the introduction of the [[graphical user interface]] and data-rich [[application program]]s like [[Lotus 1-2-3]] led to an increasing interest in using personal computers as the client-side platform of choice in [[client-server]] computing. Under this model, large mainframes and [[minicomputer]]s would be used primarily to serve up data over [[local area network]]s to microcomputers that would interpret, display and manipulate that data. For this model to work, a data access standard was a requirement – in the mainframe field it was highly likely that all of the computers in a shop were from one vendor and clients were [[computer terminal]]s talking directly to them, but in the micro field there was no such standardization and any client might access any server using any networking system. By the late 1980s there were several efforts underway to provide an abstraction layer for this purpose. Some of these were mainframe related, designed to allow programs running on those machines to translate between the variety of SQL's and provide a single common interface which could then be called by other mainframe or microcomputer programs. These solutions included IBM's Distributed Relational Database Architecture ([[DRDA]]) and [[Apple Computer]]'s [[Data Access Language]]. Much more common, however, were systems that ran entirely on microcomputers, including a complete [[protocol stack]] that included any required networking or file translation support. One of the early examples of such a system was [[Lotus Development]]'s [[Lotus DataLens|DataLens]], initially known as Blueprint. Blueprint, developed for 1-2-3, supported a variety of data sources, including SQL/DS, DB2, [[FOCUS]] and a variety of similar mainframe systems, as well as microcomputer systems like [[dBase]] and the early Microsoft/Ashton-Tate efforts that would eventually develop into [[Microsoft SQL Server]].<ref>Evan McGlinn, [https://books.google.ca/books?id=6D4EAAAAMBAJ Blueprint Lets 1-2-3 Access Outside Data"], ''InfoWorld'', 4 April 1988, p. 1, 69</ref> Unlike the later ODBC, Blueprint was a purely code-based system, lacking anything approximating a command language like SQL. Instead, programmers used [[data structure]]s to store the query information, constructing a query by linking many of these structures together. Lotus referred to these compound structures as ''query trees''.{{sfn|Geiger|1995|p=65}} Around the same time, an industry team including members from [[Sybase]] (Tom Haggin), [[Tandem Computers]] (Jim Gray & Rao Yendluri) and Microsoft (Kyle G)were working on a standardized dynamic SQL concept. Much of the system was based on Sybase's DB-Library system, with the Sybase-specific sections removed and several additions to support other platforms.{{sfn|Geiger|1995|p=86-87}} DB-Library was aided by an industry-wide move from library systems that were tightly linked to a specific language, to library systems that were provided by the [[operating system]] and required the languages on that platform to conform to its standards. This meant that a single library could be used with (potentially) any programming language on a given platform. The first draft of the ''Microsoft Data Access API'' was published in April 1989, about the same time as Lotus' announcement of Blueprint.{{sfn|Geiger|1995|p=56}} In spite of Blueprint's great lead – it was running when MSDA was still a paper project – Lotus eventually joined the MSDA efforts as it became clear that SQL would become the de facto database standard.{{sfn|Geiger|1995|p=65}} After considerable industry input, in the summer of 1989 the standard became ''SQL Connectivity'' (''SQLC'').{{sfn|Geiger|1995|p=106}} ===SAG and CLI=== In 1988 several vendors, mostly from the [[Unix]] and database communities, formed the [[SQL Access Group]] (SAG) in an effort to produce a single basic standard for the SQL language. At the first meeting there was considerable debate over whether or not the effort should work solely on the SQL language itself, or attempt a wider standardization which included a dynamic SQL language-embedding system as well, what they called a [[Call Level Interface]] (CLI).{{sfn|Geiger|1995|p=165}} While attending the meeting with an early draft of what was then still known as MS Data Access, Kyle Geiger of Microsoft invited Jeff Balboni and Larry Barnes of [[Digital Equipment Corporation]] (DEC) to join the SQLC meetings as well. SQLC was a potential solution to the call for the CLI, which was being led by DEC. The new SQLC "gang of four", MS, Tandem, DEC and Sybase, brought an updated version of SQLC to the next SAG meeting in June 1990.{{sfn|Geiger|1995|p=186-187}} The SAG responded by opening the standard effort to any competing design, but of the many proposals, only [[Oracle Corp]] had a system that presented serious competition. In the end, SQLC won the votes and became the draft standard, but only after large portions of the API were removed – the standards document was trimmed from 120 pages to 50 during this time. It was also during this period that the name Call Level Interface was formally adopted.{{sfn|Geiger|1995|p=186-187}} In 1995 SQL/CLI became part of the international SQL standard, ISO/IEC 9075-3.<ref name="ReferenceA">ISO/IEC 9075-3 – Information technology – Database languages – SQL – Part 3: Call-Level Interface (SQL/CLI)</ref> The SAG itself was taken over by the [[X/Open]] group in 1996, and, over time, became part of [[The Open Group]]'s [[Common Application Environment]]. MS continued working with the original SQLC standard, retaining many of the advanced features that were removed from the CLI version. These included features like [[Cursor (databases)#Scrollable cursors|scrollable cursors]], and [[metadata]] information queries. The commands in the API were split into groups; the Core group was identical to the CLI, the Level 1 extensions were commands that would be easy to implement in drivers, while Level 2 commands contained the more advanced features like cursors. A proposed standard was released in December 1991, and industry input was gathered and worked into the system through 1992, resulting in yet another name change to ''ODBC''.{{sfn|Geiger|1995|p=203}} ===JET and ODBC=== During this time, Microsoft was in the midst of developing their [[Microsoft Jet Database Engine|Jet]] database system. Jet combined three primary subsystems; an [[ISAM]]-based database engine (also named ''Jet'', confusingly), a C-based interface allowing applications to access that data, and a selection of driver [[Dynamic-Link Libraries|dynamic-link libraries]] (DLL) that allowed the same C interface to redirect input and output to other ISAM-based databases, like [[Paradox (database)|Paradox]] and [[xBase]]. Jet allowed using one set of calls to access common microcomputer databases in a fashion similar to Blueprint, by then renamed DataLens. However, Jet did not use SQL; like DataLens, the interface was in C and consisted of [[data structure]]s and function calls. The SAG standardization efforts presented an opportunity for Microsoft to adapt their Jet system to the new CLI standard. This would not only make Windows a premier platform for CLI development, but also allow users to use SQL to access both Jet and other databases as well. What was missing was the SQL parser that could convert those calls from their text form into the C-interface used in Jet. To solve this, MS partnered with [[Simba Technologies|PageAhead Software]] to use their existing query processor, SIMBA. SIMBA was used as a parser above Jet's C library, turning Jet into an SQL database. And because Jet could forward those C-based calls to other databases, this also allowed SIMBA to query other systems. Microsoft included drivers for Excel to turn its spreadsheet documents into SQL-accessible database tables.<ref name=simba>{{cite book | last= Harindranath | first= G | author2= Jože Zupančič | title= New perspectives on information systems development: theory, methods, and practice | url= https://books.google.com/books?id=O8Loa-c0TyoC | accessdate= 2010-07-28 | year= 2001 | publisher= Springer | isbn= 978-0-306-47251-0 | page= 451 | quote= The first ODBC drivers […] used the SIMBA query processor, which translated calls into the Microsoft Jet ISAM calls, and dispatched the calls to the appropriate ISAM driver to access the backend […] }}</ref> ===Release and continued development=== ODBC 1.0 was released in September 1992.<ref>{{cite web |url=http://www.easysoft.com/developer/interfaces/odbc/linux.html#what_is_odbc |title=Linux/UNIX ODBC – What is ODBC?}}</ref> At the time, there was little direct support for SQL databases (versus ISAM), and early drivers were noted for poor performance. Some of this was unavoidable due to the path that the calls took through the Jet-based stack; ODBC calls to SQL databases were first converted from [[Simba Technologies]]'s SQL dialect to Jet's internal C-based format, then passed to a driver for conversion back into SQL calls for the database. [[Digital Equipment]] and [[Oracle Corporation|Oracle]] both contracted [[Simba Technologies]] to develop drivers for their databases as well.<ref>[http://www.simba.com/simba-history.htm "Our History"], Simba Technologies</ref> Circa 1993, [[OpenLink Software]] shipped one of the first independently developed third-party ODBC drivers, for the [[Progress DBMS|PROGRESS DBMS]],<ref>{{cite web|last=Idehen|first=Kingsley|title=ODBC and progress V7.2d|url=https://groups.google.com/d/msg/comp.databases/ZDdiftnvkj4/AK0K2M0a0WoJ|work=Usenet Newsgroup comp.databases|accessdate=13 December 2013|authorlink=Kingsley Uyi Idehen |date=October 1994}}</ref> and soon followed with their UDBC (a cross-platform API equivalent of ODBC and the SAG/CLI) SDK and associated drivers for [[Progress Software|PROGRESS]], Sybase, Oracle, and other DBMS, for use on Unix-like OS ([[AIX]], [[HP-UX]], [[Solaris (operating system)|Solaris]], [[Linux]], etc.), [[OpenVMS|VMS]], [[Windows NT]], [[OS/2]], and other OS.<ref>{{cite web|last=Idehen|first=Kingsley|title=Need ODBC/Ingres driver for DEC OSF/1|url=https://groups.google.com/d/msg/comp.databases.oracle/HSHhNjjBgf4/47PGF35h93AJ|work=Usenet Newsgroup comp.databases.oracle|accessdate=13 December 2013|authorlink=Kingsley Uyi Idehen|date=1995-07-18}}</ref> Meanwhile, the CLI standard effort dragged on, and it was not until March 1995 that the definitive version was finalized. By then, Microsoft had already granted [[Visigenic Software]] a [[source code]] license to develop ODBC on non-Windows platforms. Visigenic ported ODBC to a wide variety of Unix platforms, where ODBC quickly became the de facto standard.<ref>Roger Sippl, [http://www.drdobbs.com/sql-access-groups-call-level-interface/184410032 "SQL Access Group's Call-Level Interface"], Dr. Dobbs, 1 February 1996</ref> "Real" CLI is rare today. The two systems remain similar, and many applications can be ported from ODBC to CLI with few or no changes.<ref>[http://publib.boulder.ibm.com/infocenter/iisclzos/v9r5/index.jsp?topic=/com.ibm.swg.im.iis.fed.classic.clientsref.doc/topics/iiyfcodbcclisimdiff.html "Similarities and differences between ODBC and CLI"], InfoSphere Classic documentation, IBM, 26 September 2008</ref> Over time, database vendors took over the driver interfaces and provided direct links to their products. Skipping the intermediate conversions to and from Jet or similar wrappers often resulted in higher performance. However, by then Microsoft had changed focus to their [[OLE DB]]<ref>[http://hal2020.com/2011/09/25/ole-db-and-sql-server-history-end-game-and-some-microsoft-dirt/]</ref> concept (now [[deprecation|deprecated]]), which provided direct access to a wider variety of data sources from [[address book]]s to text files. Several new systems followed which further turned their attention from ODBC, including [[ActiveX Data Objects]] (ADO) and [[ADO.net]], which interacted more or less with ODBC over their lifetimes. As Microsoft turned its attention away from working directly on ODBC, the Unix field was increasingly embracing it. This was propelled by two changes within the market, the introduction of [[graphical user interface]]s (GUIs) like [[GNOME]] that provided a need to access these sources in non-text form, and the emergence of [[open software]] database systems like [[PostgreSQL]] and [[MySQL]], initially under Unix. The later adoption of ODBC by Apple for using the standard Unix-side [[iODBC]] package [[Mac OS X 10.2]] (Jaguar)<ref>{{cite web|last=Anderson|first=Andrew|title=Open Database Connectivity in Jaguar|url=http://oreilly.com/pub/a/mac/2003/06/20/odbc.html|work=O'Reilly MacDevCenter.com|publisher=O'Reilly Media, Inc.|accessdate=13 December 2013|date=2003-06-20}}</ref> (which [[OpenLink Software]] had been independently providing for Mac OS X 10.0 and even Mac OS 9 since 2001<ref>{{cite web|last=Sellers|first=Dennis|title=ODBC SDK update out for Mac OS Classic, Mac OS X|url=http://www.macworld.com/article/1018465/odbc.html|work=MacWorld|publisher=IDG Consumer & SMB|accessdate=13 December 2013|date=2001-07-17}}</ref>) further cemented ODBC as the standard for cross-platform data access. [[Sun Microsystems]] used the ODBC system as the basis for their own open standard, [[Java Database Connectivity]] (JDBC). In most ways, JDBC can be considered a version of ODBC for the programming language [[Java (programming language)|Java]] instead of [[C (programming language)|C]]. JDBC-to-ODBC ''bridges'' allow Java-based programs to access data sources through ODBC drivers on platforms lacking a native JDBC driver, although these are now relatively rare. Inversely, ODBC-to-JDBC bridges allow C-based programs to access data sources through JDBC drivers on platforms or from databases lacking suitable ODBC drivers. ===ODBC today=== ODBC remains largely universal today, with drivers available for most platforms and most databases. It is not uncommon to find ODBC drivers for database engines that are meant to be embedded, like [[SQLite]], as a way to allow existing tools to act as front-ends to these engines for testing and debugging.<ref>Christian Werner, [http://www.ch-werner.de/sqliteodbc/ "SQLite ODBC Driver"]</ref> However, the rise of [[thin client]] computing using [[HTML]] as an intermediate format has reduced the need for ODBC. Many web development platforms contain direct links to target databases – MySQL being very common. In these scenarios, there is no direct client-side access nor multiple client software systems to support; everything goes through the programmer-supplied HTML application. The virtualization that ODBC offers is no longer a strong requirement, and development of ODBC is no longer as active as it once was. ===Version history=== Version history:<ref>{{cite web | url = http://www.easysoft.com/developer/interfaces/odbc/linux.html#odbc_versions | title = ODBC Versions | work = Linux/UNIX ODBC | publisher = Easysoft | accessdate = 2009-10-27 }}</ref> * 1.0: released in September 1992<ref>{{cite web | url = http://www.east.utcluj.ro/mb/mep/antal/Articole/orajdbc_2004.pdf | title = Access to an Oracle database using JDBC | first = Tiberiu Alexandru | last = Antal | publisher = Technical University of Cluj-Napoca | location = Cluj-Napoca | page = 2 | format = PDF | accessdate = 2009-10-27 | quote = ODBC 1.0 was released in September 1992 }}</ref> * 2.0: {{circa}} 1994 * 2.5 * 3.0: {{circa}} 1995, John Goodson of Intersolv and Frank Pellow and Paul Cotton of IBM provided significant input to ODBC 3.0<ref>Microsoft Corporation. Microsoft ODBC 3.0 Programmer's Reference and SDK Guide, Volume 1. Microsoft Press. February 1997. (ISBN 9781572315167)</ref> * 3.5: {{circa}} 1997 * 3.8: {{circa}} 2009, with Windows 7<ref name="ReferenceA"/><ref>{{cite web | url = http://msdn.microsoft.com/en-us/library/ee388580%28VS.85%29.aspx | title = What's New in ODBC 3.8 | publisher = Microsoft | accessdate = 2010-01-13 | quote = Windows 7 includes an updated version of ODBC, ODBC 3.8.}}</ref> ==Drivers and Managers== ===Drivers=== ODBC is based on the [[device driver]] model, where the driver encapsulates the logic needed to convert a standard set of commands and functions into the specific calls required by the underlying system. For instance, a [[printer driver]] presents a standard set of printing commands, the API, to applications using the printing system. Calls made to those APIs are converted by the driver into the format used by the actual hardware, say [[PostScript]] or [[Printer Command Language|PCL]]. In the case of ODBC, the drivers encapsulate many functions that can be broken down into several broad categories. One set of functions is primarily concerned with finding, connecting to and disconnecting from the DBMS that driver talks to. A second set is used to send SQL commands from the ODBC system to the DBMS, converting or interpreting any commands that are not supported internally. For instance, a DBMS that does not support [[Cursor (databases)|cursors]] can emulate this functionality in the driver. Finally, another set of commands, mostly used internally, is used to convert data from the DBMS's internal formats to a set of standardized ODBC formats, which are based on the C language formats. An ODBC driver enables an ODBC-compliant application to use a ''data source'', normally a DBMS. Some non-DBMS drivers exist, for such data sources as [[Comma-separated values|CSV]] files, by implementing a small DBMS inside the driver itself. ODBC drivers exist for most DBMSs, including [[Oracle database|Oracle]], [[PostgreSQL]], [[MySQL]], [[Microsoft SQL Server]] (but not for the [[SQL Server Compact|Compact aka CE edition]]), [[Adaptive Server Enterprise|Sybase ASE]], [[SAP HANA]]<ref>{{Cite web|url=http://db-engines.com/en/system/SAP+HANA|title=SAP HANA System Properties|website=db-engines.com|access-date=2016-03-28}}</ref><ref>{{Cite web|url=http://help.sap.com/saphelp_hanaplatform/helpdata/en/66/a4169b84b2466892e1af9781049836/content.htm|title=Connect to SAP HANA via ODBC - SAP HANA Developer Guide for SAP HANA Studio - SAP Library|website=help.sap.com|access-date=2016-03-28}}</ref> and [[IBM DB2|DB2]]. Because different technologies have different capabilities, most ODBC drivers do not implement all functionality defined in the ODBC standard. Some drivers offer extra functionality not defined by the standard. ===Driver Manager=== Device drivers are normally enumerated, set up and managed by a separate Manager layer, which may provide additional functionality. For instance, printing systems often include functionality to provide [[spooling]] functionality on top of the drivers, providing print spooling for any supported printer. In ODBC the Driver Manager (DM) provides these features.<ref>{{cite web|last=Sybase|title=Introduction to ODBC|url=http://infocenter.sybase.com/help/index.jsp?topic=/com.sybase.help.sdk_12.5.1.aseodbc/html/aseodbc/aseodbc5.htm|work=http://infocenter.sybase.com/help/index.jsp?topic=/com.sybase.help.sdk_12.5.1.aseodbc/html/aseodbc/aseodbc5.htm|publisher=Sybase|accessdate=8 October 2011}}</ref> The DM can enumerate the installed drivers and present this as a list, often in a GUI-based form. But more important to the operation of the ODBC system is the DM's concept of a ''Data Source Name'' (DSN). DSNs collect additional information needed to connect to a ''specific'' data source, versus the DBMS itself. For instance, the same [[MySQL]] driver can be used to connect to any MySQL server, but the connection information to connect to a local private server is different from the information needed to connect to an internet-hosted public server. The DSN stores this information in a standardized format, and the DM provides this to the driver during connection requests. The DM also includes functionality to present a list of DSNs using human readable names, and to select them at run-time to connect to different resources. The DM also includes the ability to save partially complete DSN's, with code and logic to ask the user for any missing information at runtime. For instance, a DSN can be created without a required password. When an ODBC application attempts to connect to the DBMS using this DSN, the system will pause and ask the user to provide the password before continuing. This frees the application developer from having to create this sort of code, as well as having to know which questions to ask. All of this is included in the driver and the DSNs. ==Bridging configurations== A ''bridge'' is a special kind of driver: a driver that uses another driver-based technology. ===ODBC-to-JDBC (ODBC-JDBC) bridges=== An ODBC-JDBC bridge consists of an ''ODBC'' driver which uses the services of a [[JDBC type 1 driver|JDBC driver]] to connect to a database. This driver translates ODBC function-calls into JDBC method-calls. Programmers usually use such a bridge when they lack an ODBC driver for some database but have access to a JDBC driver. Example: [https://www.progress.com/odbc/sequelink SequeLink ODBC-JDBC Bridge] ===JDBC-to-ODBC (JDBC-ODBC) bridges=== A JDBC-ODBC bridge consists of a [[JDBC driver]] which employs an ODBC driver to connect to a target database. This driver translates JDBC [[Method (computer science)|method]] calls into ODBC function calls. Programmers usually use such a bridge when a given database lacks a JDBC driver. [[Sun Microsystems]] included one such bridge in the [[JVM]], but viewed it as a stop-gap measure while few JDBC drivers existed. Sun never intended its bridge for production environments, and generally recommended against its use. {{As of|2008}} independent data-access vendors deliver JDBC-ODBC bridges which support current standards for both mechanisms, and which far outperform the JVM built-in.{{Citation needed|date=July 2008}} Example: [https://www.progress.com/jdbc/sequelink SequeLink JDBC-ODBC Bridge] The JDBC-ODBC bridge was dropped in Java 8. ===OLE DB-to-ODBC bridges=== An OLE DB-ODBC bridge consists of an [[OLE DB]] Provider which uses the services of an ODBC driver to connect to a target database. This provider translates OLE DB [[Method (computer science)|method]] calls into ODBC function calls. Programmers usually use such a bridge when a given database lacks an OLE DB provider. Microsoft ships one, MSDASQL.DLL, as part of the [[MDAC]] [[system component bundle]], together with other database drivers, to simplify development in COM-aware languages (e.g. [[Visual Basic]]). Third parties have also developed such, notably [[OpenLink Software]] whose 64-bit OLE DB Provider for ODBC Data Sources filled the gap when Microsoft initially deprecated this bridge for their 64-bit OS.<ref name="msdasql">''Microsoft'', "Data Access Technologies Road Map", Deprecated MDAC Components, ''Microsoft'' [http://msdn.microsoft.com/library/default.asp?url=/library/en-us/ado270/htm/mdrefodbcprovspec.asp "ADO Programmer's Guide" Appendix A: Providers, Microsoft OLE DB Provider for ODBC], retrieved July 30, 2005. {{webarchive |url=https://web.archive.org/web/20011005101137/http://msdn.microsoft.com/library/default.asp?url=/library/en-us/ado270/htm/mdrefodbcprovspec.asp |date=October 5, 2001 }}</ref> (Microsoft later relented, and 64-bit Windows starting with [[Windows Server 2008]] and [[Windows Vista SP1]] have shipped with a 64-bit version of MSDASQL.) Example: [https://www.progress.com/oledb/sequelink SequeLink OLEDB-ODBC Bridge] ===ADO.NET-to-ODBC bridges=== An ADO.NET-ODBC bridge consists of an [[ADO.NET data provider|ADO.NET Provider]] which uses the services of an ODBC driver to connect to a target database. This provider translates ADO.NET [[Method (computer science)|method]] calls into ODBC function calls. Programmers usually use such a bridge when a given database lacks an ADO.NET provider. Microsoft ships one as part of the [[MDAC]] [[system component bundle]], together with other database drivers, to simplify development in [[C Sharp (programming language)|C#]]. Third parties have also developed such. Example: [https://www.progress.com/net/sequelink SequeLink ADO.NET-ODBC Bridge] ==See also== * [[GNU Data Access]] * [[Windows Open Services Architecture]] * [[ADO.NET]] * [[ODBC Administrator]] * [https://www.progress.com/odbc/microsoft-sql-server SQL Server ODBC Driver by DataDirect] ==References== ;Citations {{Reflist}} ;Bibliography {{refbegin}} * {{cite book|first= Kyle|last= Geiger|url=https://books.google.ca/books?id=G-ZQAAAAMAAJ&|title=Inside ODBC|publisher= Microsoft Press|year= 1995 |ref=harv}} {{refend}} ==External links== * [http://support.microsoft.com/kb/110093 Microsoft ODBC Overview] * [http://publib.boulder.ibm.com/infocenter/iseries/v5r3/topic/rzaii/rzaiiodbcadm.htm OS400 and i5OS ODBC Administration] * [http://www.roth.net/perl/odbc/conf/sld002.htm Presentation slides from www.roth.net] * [http://blogs.msdn.com/data/archive/2006/12/05/data-access-api-of-the-day-part-i.aspx Microsoft ODBC & Data Access APIs History Article] {{Microsoft APIs}} {{Authority control}} [[Category:Computer programming]] [[Category:Microsoft application programming interfaces]] [[Category:Database APIs]] [[Category:SQL data access]]'