Editing Open Database Connectivity (section)

===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 Uyi |title=ODBC and progress V7.2d |url=https://groups.google.com/d/msg/comp.databases/ZDdiftnvkj4/AK0K2M0a0WoJ |work=Usenet Newsgroup comp.databases |access-date=13 December 2013 |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 Uyi |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 |access-date=13 December 2013 |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 the [[classic Mac OS]], and a wide variety of Unix platforms, where ODBC quickly became the de facto standard.<ref>Sippl, Roger (1996) [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>{{Cite web|url=http://hal2020.com/2011/09/25/ole-db-and-sql-server-history-end-game-and-some-microsoft-dirt/|title = OLE DB and SQL Server: History, End-Game, and some Microsoft "dirt"|date = 25 September 2011}}</ref> concept (recently reinstated <ref>{{cite web |url=https://blogs.msdn.microsoft.com/sqlnativeclient/2017/10/06/announcing-the-new-release-of-ole-db-driver-for-sql-server/ |title=Announcing the new release of OLE DB Driver for SQL Server |date=6 October 2017 }}</ref>), 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. |access-date=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 |access-date=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.