Before ODBC The introduction of the
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 from the
Ingres project. These systems may or may not allow other applications to access the data directly, and those that did use a wide variety of methodologies. The introduction of
SQL aimed to solve the problem of
language standardization, although substantial differences in implementation remained. 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. This led to the concept of
Embedded SQL, which allowed
SQL code to be
embedded within another language. For instance, a SQL statement like SELECT * FROM city could be inserted as text within C source code, and during
compiling it would be converted into a custom format that directly called a function within a
library that would pass the statement into the SQL system. Results returned from the statements would be interpreted back into C data formats like char* or char[] 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 Db2 would look very different from one that called into their own
SQL/DS. 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 interfaces 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 programs 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
minicomputers would be used primarily to serve up data over
local area networks 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 terminals 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
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. Unlike the later ODBC, Blueprint was a purely code-based system, lacking anything approximating a command language like SQL. Instead, programmers used
data structures to store the query information, constructing a query by linking many of these structures together. Lotus referred to these compound structures as
query trees. Around the same time, an industry team including members from
Sybase (Tom Haggin),
Tandem Computers (
Jim Gray & Rao Yendluri) and Microsoft (Kyle Geiger) 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. 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. 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. After considerable industry input, in the summer of 1989 the standard became
SQL Connectivity (
SQLC).
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). 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. 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. In 1995 SQL/CLI became part of the international SQL standard, ISO/IEC 9075-3. 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
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.
JET and ODBC During this time, Microsoft was in the midst of developing their
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 (DLL) that allowed the same C interface to redirect input and output to other ISAM-based databases, like
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 structures 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
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.
Release and continued development ODBC 1.0 was released in September 1992. 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 both contracted
Simba Technologies to develop drivers for their databases as well. Circa 1993, OpenLink Software shipped one of the first independently developed third-party ODBC drivers, for the
PROGRESS DBMS, and soon followed with their UDBC (a cross-platform API equivalent of ODBC and the SAG/CLI) SDK and associated drivers for
PROGRESS, Sybase, Oracle, and other DBMS, for use on Unix-like OS (
AIX,
HP-UX,
Solaris,
Linux, etc.),
VMS,
Windows NT,
OS/2, and other OS. 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 the
classic Mac OS, and a wide variety of Unix platforms, where ODBC quickly became the de facto standard. "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. 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 concept (recently reinstated ), which provided direct access to a wider variety of data sources from
address books 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 interfaces (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) (which OpenLink Software had been independently providing for Mac OS X 10.0 and even Mac OS 9 since 2001) 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 instead of
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 in wide use 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. In recent years, ODBC has also been adopted for connecting to cloud-based data sources and SaaS platforms such as Salesforce, Google BigQuery, and Snowflake. Cross-platform driver availability (for Windows, macOS, and Linux) has enabled integration with modern analytics and business intelligence tools like Power BI, Tableau, and RStudio. This has extended ODBC's relevance beyond traditional relational databases into cloud data warehousing and data science workflows.
Version history ODBC specifications Source: • 1.0: released in September 1992 • 2.0: 1994 • 2.5 • 3.0: 1995, John Goodson of Intersolv and Frank Pellow and Paul Cotton of IBM provided significant input to ODBC 3.0 • 3.5: 1997 • 3.8: 2009, with Windows 7 • 4.0: Development announced June 2016 with first implementation with SQL Server 2017 released Sep 2017 and additional desktop drivers late 2018 final spec on Github
Desktop Database Drivers Source: • 1.0 (1993–08): Used the SIMBA query processor produced by PageAhead Software. • 2.0 (1994–12): Used with ODBC 2.0. • 3.0 (1995–10): Supports
Windows 95 and Windows NT Workstation or NT Server 3.51. Only 32-bit drivers were included in this release. • 3.5 (1996–10): Supports double-byte character set (DBCS), and accommodated the use of File data source names (DSNs). The Microsoft Access driver was released in an RISC version for use on Alpha platforms for Windows 95/98 and
Windows NT 3.51 and later operating systems. • 4.0 (late 1998): Support Microsoft Jet Engine Unicode format along with compatibility for ANSI format of earlier versions. ==Drivers and Managers==