[citation needed] 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.
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 Simba Technologies during the early 1990s, and became the basis for the Call Level Interface (CLI) standardized by SQL Access Group in the Unix and mainframe field.
The introduction of SQL aimed to solve the problem of language standardization, although substantial differences in implementation remained.
Results returned from the statements would be interpreted back into C data formats like char * using similar library code.
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.
These solutions included IBM's Distributed Relational Database Architecture (DRDA) and Apple Computer's Data Access Language.
[1] Unlike the later ODBC, Blueprint was a purely code-based system, lacking anything approximating a command language like SQL.
[2] 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.
The first draft of the Microsoft Data Access API was published in April 1989, about the same time as Lotus' announcement of Blueprint.
[7] 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.
MS continued working with the original SQLC standard, retaining many of the advanced features that were removed from the CLI version.
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 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.
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.
[11] At the time, there was little direct support for SQL databases (versus ISAM), and early drivers were noted for poor performance.
[12] Circa 1993, OpenLink Software shipped one of the first independently developed third-party ODBC drivers, for the PROGRESS DBMS,[13] 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.
By then, Microsoft had already granted Visigenic Software a source code license to develop ODBC on non-Windows platforms.
However, by then Microsoft had changed focus to their OLE DB[17] concept (recently reinstated [18]), which provided direct access to a wider variety of data sources from address books to text files.
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.
Sun Microsystems used the ODBC system as the basis for their own open standard, Java Database Connectivity (JDBC).
DSNs collect additional information needed to connect to a specific data source, versus the DBMS itself.
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.
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.
As of 2008[update] independent data-access vendors deliver JDBC-ODBC bridges which support current standards for both mechanisms, and which far outperform the JVM built-in.
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.
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.
Microsoft ships one as part of the MDAC system component bundle, together with other database drivers, to simplify development in C#.