Open Database Connectivity — Safekipedia Adventurer

In computing, Open Database Connectivity (ODBC) is a C language standard application programming interface. It helps programs talk to different types of database management systems.

ODBC works by using something called an ODBC driver. This driver acts like a middle layer. The program sends requests using ODBC, and the driver translates them so the database can understand. This is like how a printer driver helps your computer work with different printers.

ODBC was first created by Microsoft and Simba Technologies in the early 1990s. It is now widely used. Because of ODBC, a program that works with one database can easily work with another by switching the driver. This makes it easier for developers to create programs that work with many databases, such as Microsoft Excel files, address book systems, or simple text files like comma-separated values (CSV).

History

Before ODBC

When mainframe computers with databases became common in the 1970s, many ways to get data started. These systems used simple commands. Popular examples were SQL from IBM and QUEL from the Ingres project. Some let other programs use the data, but each did it differently.

SQL wanted the same rules for everyone, but it still worked differently in many ways. Because SQL had few programming features, people wanted to use it in programs written in languages like Fortran or C. This led to Embedded SQL, where SQL commands were put inside another language’s code. But this had problems, like needing lots of work to change even small parts.

Early efforts

In the mid-1980s, personal computers became very popular, especially for tasks that needed to show lots of data, like spreadsheets such as Lotus 1-2-3. This created a need for a standard way to connect different types of computers and databases. Many companies worked on solutions, including IBM and Apple. One early system was Lotus Development’s DataLens, which helped connect to many types of databases but used its own way of building queries instead of SQL.

Around this time, a group including Sybase, Tandem Computers, and Microsoft worked on a new idea for dynamic SQL. This led to the first version of what would become the Microsoft Data Access API in April 1989. Lotus later joined these efforts as SQL became the standard way to talk to databases.

SAG and CLI

In 1988, several companies formed the SQL Access Group (SAG) to create a single standard for SQL. They debated whether to focus only on the SQL language or also create a system for embedding SQL in programs, called a Call Level Interface (CLI). After discussions, they chose to support CLI. The group included Microsoft, Tandem, Digital Equipment Corporation, and Sybase. They updated their idea called SQLC for the SAG meeting in June 1990. After voting, SQLC became the basis for the new standard, though many parts were simplified.

JET and ODBC

Microsoft was also working on their Jet database system, which included tools to connect to different databases using C commands instead of SQL. They saw the SAG efforts as a chance to update Jet to work with the new CLI standard. To do this, Microsoft worked with PageAhead Software to add an SQL parser called SIMBA, allowing Jet to understand SQL and connect to other databases like Excel.

Release and continued development

ODBC 1.0 was released in September 1992. Early versions had some performance issues because of how they processed commands. Over time, companies like OpenLink Software created their own ODBC drivers for various databases and operating systems. As ODBC grew, Microsoft shifted focus to other systems like OLE DB, but ODBC remained important, especially on Unix systems and later for cloud databases.

ODBC today

ODBC is still widely used today. Drivers exist for almost every platform and database, including cloud services like Salesforce and Google BigQuery. This makes ODBC useful for modern tools that analyze data.

Version history

ODBC specifications

Source:

1.0: released in September 1992
2.0: c. 1994
2.5
3.0: c. 1995, John Goodson of Intersolv and Frank Pellow and Paul Cotton of IBM provided significant input to ODBC 3.0
3.5: c. 1997
3.8: c. 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

ODBC is like a special helper that lets different programs talk to many databases. Imagine it as a translator that can speak lots of languages.

The part called the driver knows how to talk to one type of database. It changes general requests into the exact commands that database understands. For example, it can help change data formats so everything works right.

There is also something called a Driver Manager. It helps manage all the different drivers. It gives programs a list of databases to choose from. It also stores special settings for each database. This makes it easier for programs to connect without needing extra information every time.

Bridging configurations

A bridge is a special tool that helps different kinds of software talk to each other. It uses one kind of technology to work with another.

ODBC-to-JDBC (ODBC-JDBC) bridges

An ODBC-JDBC bridge uses an ODBC tool to connect to a database with a JDBC tool. This helps when someone needs to connect to a database but does not have the right ODBC tool but has a JDBC tool. Examples include the OpenLink ODBC-JDBC Bridge and the SequeLink ODBC-JDBC Bridge.

JDBC-to-ODBC (JDBC-ODBC) bridges

A JDBC-ODBC bridge uses a JDBC tool to connect to a database with an ODBC tool. This helps when someone needs to connect to a database but does not have the right JDBC tool but has an ODBC tool. Examples include the OpenLink JDBC-ODBC Bridge, the SequeLink JDBC-ODBC Bridge, and the ZappySys JDBC-ODBC Bridge.

OLE DB-to-ODBC bridges

An OLE DB-to-ODBC bridge uses an OLE DB tool to connect to a database with an ODBC tool. This helps when someone needs to connect to a database but does not have the right OLE DB tool but has an ODBC tool. Examples include the OpenLink OLEDB-ODBC Bridge and the SequeLink OLEDB-ODBC Bridge.

ADO.NET-to-ODBC bridges

An ADO.NET-to-ODBC bridge uses an ADO.NET tool to connect to a database with an ODBC tool. This helps when someone needs to connect to a database but does not have the right ADO.NET tool but has an ODBC tool. Examples include the OpenLink ADO.NET-ODBC Bridge and the SequeLink ADO.NET-ODBC Bridge.