Editing Open Database Connectivity (section)

===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 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 (programming language)|C]]. This led to the concept of [[Embedded SQL]], which allowed [[PostQUEL|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 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.