Из Википедии, бесплатной энциклопедии
  (Перенаправлено из ODBC )
Перейти к навигации Перейти к поиску

В вычислении , Open Database Connectivity ( ODBC ) представляет собой стандартный интерфейс прикладного программирования (API) для доступа к системам управления базами данных (СУБД). Разработчики ODBC стремились сделать его независимым от систем баз данных и операционных систем . [ необходима цитата ] Приложение, написанное с использованием ODBC, может быть перенесено на другие платформы, как на стороне клиента, так и на стороне сервера, с небольшими изменениями в коде доступа к данным.

ODBC обеспечивает независимость СУБД за счет использования драйвера ODBC в качестве уровня трансляции между приложением и СУБД. Приложение использует функции ODBC через диспетчер драйверов ODBC, с которым оно связано, и драйвер передает запрос в СУБД. Драйвер ODBC можно рассматривать как аналог драйвера принтера или другого драйвера, предоставляющий стандартный набор функций для использования приложением и реализующий специфические для СУБД функциональные возможности. Приложение, которое может использовать ODBC, называется «ODBC-совместимым». Любое ODBC-совместимое приложение может получить доступ к любой СУБД, для которой установлен драйвер. Существуют драйверы для всех основных СУБД, многих других источников данных, таких как системы адресных книг и Microsoft Excel., и даже для текстовых файлов или файлов с разделителями-запятыми (CSV).

ODBC был первоначально разработан Microsoft и Simba Technologies в начале 1990-х годов и стал основой для интерфейса уровня вызовов (CLI), стандартизованного SQL Access Group в области Unix и мэйнфреймов . ODBC сохранил несколько функций, которые были удалены в рамках работы с интерфейсом командной строки. Полный ODBC позже был перенесен обратно на эти платформы и стал де-факто стандартом, значительно более известным, чем CLI. Интерфейс командной строки остается аналогичным ODBC, и приложения можно переносить с одной платформы на другую с небольшими изменениями.

История [ править ]

До ODBC [ править ]

Внедрение ЭВМ -На реляционной базы данных в течение 1970 - х годов привели к распространению методов доступа к данным. Обычно эти системы работали вместе с простым командным процессором, который позволял пользователям вводить английские команды и получать выходные данные. Самыми известными примерами являются SQL от IBM и QUEL из проекта Ingres . Эти системы могут разрешать, а могут и не разрешать другим приложениям получать прямой доступ к данным, а также тем, которые действительно используют широкий спектр методологий. Введение SQL было направлено на решение проблемы стандартизации языка , хотя существенные различия в реализации остались.

Поскольку в языке SQL были только элементарные функции программирования, пользователи часто хотели использовать SQL в программе, написанной на другом языке, скажем, на Фортране или Си . Это привело к концепции Embedded SQL , которая позволила встраивать код SQL в другой язык. Например, такой оператор SQL может быть вставлен в виде текста в исходный код C, и во время компиляции он будет преобразован в пользовательский формат, который напрямую вызывает функцию в библиотеке , которая передаст оператор в систему SQL. Результаты, возвращаемые операторами, будут интерпретироваться обратно в форматы данных C, как при использовании аналогичного библиотечного кода.SELECT * FROM citychar *

Было несколько проблем с подходом Embedded SQL. Как различные разновидности SQL, встроенного SQLs , которые использовали их сильно различались, а не только с платформы на платформу, но даже через языки на одной платформе - это система , которая позволила вызовы в IBM «s DB2 будет выглядеть очень отличается от той , которая называется в собственный SQL / DS . [ сомнительно - обсудить ] Другая ключевая проблема концепции Embedded SQL заключалась в том, что код SQL можно было изменить только в исходном коде программы, поэтому даже небольшие изменения в запросе требовали значительных усилий программиста для модификации. Рынок SQL назвал это статическим SQL , а не динамическим.которые можно было изменить в любое время, например интерфейсы командной строки , поставляемые почти со всеми системами SQL, или программный интерфейс, в котором SQL оставался в виде простого текста до тех пор, пока он не был вызван. Системы динамического SQL стали основным направлением деятельности поставщиков SQL в 1980-х годах.

У старых баз данных мэйнфреймов и основанных на них новых систем на базе микрокомпьютеров обычно не было командного процессора, подобного SQL, между пользователем и ядром базы данных. Вместо этого доступ к данным осуществлялся непосредственно программой - программной библиотекой в ​​случае больших систем мэйнфреймов или интерфейсом командной строки или системой интерактивных форм в случае dBASE.и подобные приложения. Данные из dBASE обычно не могут быть доступны напрямую другим программам, работающим на машине. Этим программам может быть предоставлен способ доступа к этим данным, часто через библиотеки, но он не будет работать с каким-либо другим механизмом базы данных или даже с другими базами данных в том же механизме. Фактически, все такие системы были статичными, что создавало значительные проблемы.

Ранние попытки [ править ]

К середине 1980-х годов быстрое совершенствование микрокомпьютеров, и особенно внедрение графического пользовательского интерфейса и прикладных программ с большим объемом данных, таких как Lotus 1-2-3, привело к растущему интересу к использованию персональных компьютеров в качестве предпочтительной клиентской платформы. в клиент-серверных вычислениях. Согласно этой модели, большие мэйнфреймы и миникомпьютеры будут использоваться в первую очередь для передачи данных по локальным сетям на микрокомпьютеры, которые будут интерпретировать, отображать и манипулировать этими данными. Для работы этой модели требовался стандарт доступа к данным - в области мэйнфреймов весьма вероятно, что все компьютеры в магазине принадлежат одному поставщику, а клиенты -компьютерные терминалы общаются с ними напрямую, но в микрополе такой стандартизации не было, и любой клиент мог получить доступ к любому серверу с использованием любой сетевой системы.

К концу 1980-х было предпринято несколько попыток предоставить для этой цели уровень абстракции. Некоторые из них были связаны с мэйнфреймами и были разработаны для того, чтобы программы, работающие на этих машинах, могли выполнять трансляцию между различными SQL и обеспечивать единый общий интерфейс, который затем мог быть вызван другими мэйнфреймами или микрокомпьютерами. Эти решения включены Распределенная реляционная база данных компании IBM Architecture ( DRDA ) и компании Apple Computer «s доступа к данным языка . Однако гораздо более распространенными были системы, которые полностью работали на микрокомпьютерах, включая полный стек протоколов, который включал любую необходимую поддержку сети или трансляции файлов.

Одним из первых примеров такой системы был Lotus Development «s DataLens , первоначально известный как Blueprint. Blueprint, разработанный для 1-2-3, поддерживал множество источников данных, включая SQL / DS, DB2, FOCUS и множество подобных систем мэйнфреймов, а также микрокомпьютерные системы, такие как dBase и ранние разработки Microsoft / Ashton-Tate, которые в конечном итоге разовьется в Microsoft SQL Server . [1] В отличие от более позднего ODBC, Blueprint был системой, основанной исключительно на коде, без чего-либо, приближающегося к командному языку, подобному SQL. Вместо этого программисты использовали структуры данных.для хранения информации о запросе, построение запроса путем связывания многих из этих структур вместе. Lotus называл эти составные структуры деревьями запросов . [2]

Примерно в то же время отраслевая команда, в которую входили представители Sybase (Том Хаггин), Tandem Computers ( Джим Грей и Рао Йендлури) и Microsoft (Кайл Джи), работала над стандартизированной концепцией динамического SQL. Большая часть системы была основана на системе Sybase DB-Library с удаленными разделами, специфичными для Sybase, и несколькими дополнениями для поддержки других платформ. [3] DB-Library способствовал общеотраслевой переход от библиотечных систем, которые были тесно связаны с конкретным языком, к библиотечным системам, которые были предоставлены операционной системой.и требовал, чтобы языки на этой платформе соответствовали ее стандартам. Это означало, что одну библиотеку можно было использовать (потенциально) с любым языком программирования на данной платформе.

Первый черновик Microsoft Data Access API был опубликован в апреле 1989 года, примерно в то же время, когда Lotus анонсировал Blueprint. [4] Несмотря на большое лидерство Blueprint - он работал, когда MSDA еще оставалось бумажным проектом - Lotus в конце концов присоединился к усилиям MSDA, когда стало ясно, что SQL станет стандартом де-факто для баз данных. [2] Летом 1989 года после значительного вклада отрасли стандартом стал SQL Connectivity ( SQLC ). [5]

SAG и CLI [ править ]

В 1988 году несколько поставщиков, в основном из сообществ Unix и баз данных, сформировали SQL Access Group (SAG), чтобы создать единый базовый стандарт для языка SQL. На первой встрече возникли серьезные споры о том, должны ли усилия работать исключительно на самом языке SQL или пытаться более широкая стандартизация, которая также включала динамическую систему встраивания языка SQL, которую они назвали интерфейсом уровня вызова (CLI). . [6] Присутствуя на встрече с ранним проектом того, что тогда еще называлось MS Data Access, Кайл Гейгер из Microsoft пригласил Джеффа Балбони и Ларри Барнса из Digital Equipment Corporation.(DEC), чтобы также присоединиться к собраниям SQLC. SQLC был потенциальным решением для вызова CLI, которым руководила DEC.

Новая «группа из четырех» SQLC, MS, Tandem, DEC и Sybase, представила обновленную версию SQLC на следующем собрании SAG в июне 1990 года. [7] SAG ответила, открыв стандартные усилия для любой конкурирующей разработки, кроме из множества предложений только Oracle Corp имела систему, которая представляла серьезную конкуренцию. В конце концов, SQLC получил голоса и стал черновиком стандарта, но только после того, как большая часть API была удалена - за это время документ стандартов был сокращен со 120 до 50 страниц. Также в этот период было официально принято название Call Level Interface. [7] В 1995 году SQL / CLI стал частью международного стандарта SQL ISO / IEC 9075-3. [8] Сама SAG была передана X / Openгруппа в 1996 году, и, со временем, стал частью The Open Group «s Common Application окружающей среды .

MS продолжила работу с исходным стандартом SQLC, сохранив многие расширенные функции, которые были удалены из версии CLI. К ним относятся такие функции, как прокручиваемые курсоры и запросы информации о метаданных . Команды в API были разделены на группы; Основная группа была идентична интерфейсу командной строки, расширения уровня 1 были командами, которые было бы легко реализовать в драйверах, а команды уровня 2 содержали более продвинутые функции, такие как курсоры. Предлагаемый стандарт был выпущен в декабре 1991 года, и отраслевые данные были собраны и внедрены в систему до 1992 года, что привело к еще одному изменению названия на ODBC . [9]

JET и ODBC [ править ]

В это время Microsoft занималась разработкой своей системы баз данных Jet . Jet объединил три основные подсистемы; ISAM основанное ядро базы данных (также названный Джет , смешения), интерфейс C-основе позволяет приложениям получать доступ к этим данным и выбор драйвера динамически подключаемых библиотек (DLL) , что позволило один и тот же интерфейс C для ввода и вывода Перенаправление на другие базы данных на основе ISAM, такие как Paradox и xBase . Jet позволял использовать один набор вызовов для доступа к общим базам данных микрокомпьютеров аналогично Blueprint, к тому времени переименованному в DataLens. Однако Jet не использовал SQL; как и DataLens, интерфейс был на C и состоял из структур данных и вызовы функций.

Усилия по стандартизации SAG предоставили Microsoft возможность адаптировать свою систему Jet к новому стандарту CLI. Это не только сделает Windows ведущей платформой для разработки интерфейса командной строки, но также позволит пользователям использовать SQL для доступа как к Jet, так и к другим базам данных. Чего не хватало, так это анализатора SQL, который мог преобразовывать эти вызовы из их текстовой формы в C-интерфейс, используемый в Jet. Чтобы решить эту проблему, MS заключила партнерское соглашение с PageAhead Software, чтобы использовать их существующий процессор запросов SIMBA. SIMBA использовалась в качестве парсера над библиотекой C Jet, превращая Jet в базу данных SQL. А поскольку Jet мог перенаправлять эти вызовы на основе C в другие базы данных, это также позволяло SIMBA запрашивать другие системы. Microsoft включила драйверы для Excel, чтобы преобразовать свои электронные таблицы в таблицы базы данных, доступные для SQL. [10]

Выпуск и продолжение разработки [ править ]

ODBC 1.0 был выпущен в сентябре 1992 года. [11] В то время было мало прямой поддержки для баз данных SQL (по сравнению с ISAM), и ранние драйверы были отмечены низкой производительностью. Отчасти это было неизбежно из-за пути, по которому вызовы проходили через стек на основе Jet; Вызовы ODBC к базам данных SQL сначала преобразовывались из диалекта SQL Simba Technologies во внутренний C-формат Jet, а затем передавались драйверу для обратного преобразования в вызовы SQL для базы данных. Digital Equipment и Oracle заключили с Simba Technologies контракт на разработку драйверов для своих баз данных. [12]

Circa 1993, OpenLink Software поставляется один из первых самостоятельно разработанных драйверов ODBC сторонних для PROGRESS СУБД , [13] и вскоре последовали их UDBC (кросс-платформенный API эквивалент ODBC и SAG / CLI) SDK и связанные с ними драйверы для PROGRESS , Sybase, Oracle и других СУБД для использования в Unix-подобных ОС ( AIX , HP-UX , Solaris , Linux и т. д.), VMS , Windows NT , OS / 2 и других ОС. [14]

Тем временем работа над стандартом CLI затянулась, и только в марте 1995 года окончательная версия была доработана. К тому времени, Microsoft уже получил Visigenic Software с исходным кодом лицензии на разработку ODBC на платформах , отличных от Windows. Visigenic перенес ODBC на широкий спектр платформ Unix, где ODBC быстро стал стандартом де-факто. [15] «Настоящий» интерфейс командной строки сегодня - редкость. Эти две системы остаются похожими, и многие приложения могут быть перенесены с ODBC на CLI с небольшими изменениями или без них. [16]

Со временем поставщики баз данных переняли интерфейсы драйверов и предоставили прямые ссылки на свои продукты. Пропуск промежуточных преобразований в Jet или аналогичные оболочки и обратно часто приводил к повышению производительности. Однако к тому времени Microsoft сменила фокус на свою концепцию OLE DB [17] (недавно восстановленную [18] ), которая обеспечивала прямой доступ к большему количеству источников данных от адресных книг до текстовых файлов. За этим последовало несколько новых систем, которые в дальнейшем отвлекли их внимание от ODBC, в том числе объекты данных ActiveX (ADO) и ADO.net , которые более или менее взаимодействовали с ODBC в течение своего срока службы.

По мере того как Microsoft отвлекалась от работы непосредственно над ODBC, область Unix все больше охватывала его. Этому способствовали два изменения на рынке: введение графических пользовательских интерфейсов (GUI), таких как GNOME, которые обеспечили доступ к этим источникам в нетекстовой форме, и появление систем баз данных с открытым программным обеспечением, таких как PostgreSQL и MySQL , первоначально под управлением Unix. Позже Apple приняла ODBC для использования стандартного пакета iODBC на стороне Unix Mac OS X 10.2 (Jaguar) [19] (который OpenLink Software независимо предоставлял для Mac OS X 10.0 и даже Mac OS 9 с 2001 года [20]) дальнейшее закрепление ODBC в качестве стандарта для межплатформенного доступа к данным.

Sun Microsystems использовала систему ODBC в качестве основы для своего собственного открытого стандарта Java Database Connectivity (JDBC). В большинстве способов, JDBC можно считать версию ODBC для языка программирования Java вместо C . Мосты JDBC-ODBC позволяют программам на основе Java получать доступ к источникам данных через драйверы ODBC на платформах, не имеющих встроенного драйвера JDBC, хотя сейчас это относительно редко. И наоборот, мосты ODBC-JDBC позволяют программам на основе C получать доступ к источникам данных через драйверы JDBC на платформах или из баз данных, в которых отсутствуют подходящие драйверы ODBC.

ODBC сегодня [ править ]

ODBC остается широко используемым сегодня, с драйверами, доступными для большинства платформ и большинства баз данных. Нередко можно найти драйверы ODBC для механизмов баз данных, которые предназначены для встраивания, например SQLite , как способ, позволяющий существующим инструментам выступать в качестве внешних интерфейсов для этих механизмов для тестирования и отладки. [21]

Однако рост числа тонких клиентов, использующих HTML в качестве промежуточного формата, снизил потребность в ODBC. Многие платформы веб-разработки содержат прямые ссылки на целевые базы данных - MySQL очень распространен. В этих сценариях нет прямого доступа на стороне клиента или поддержки нескольких клиентских программных систем; все проходит через предоставленное программистом HTML-приложение. Виртуализация, которую предлагает ODBC, больше не является серьезным требованием, и разработка ODBC уже не так активна, как раньше. [ необходима цитата ]Но когда ODBC больше не является строгим требованием для программирования клиент-сервер, ODBC стал более важным для доступа к данным и виртуализации данных, интеграции данных в сценариях анализа данных и науки о данных. Эти новые требования отражены в новых функциях ODBC 4.0, таких как полуструктурированные и иерархические данные, веб-аутентификация и повышение производительности.

История версий [ править ]

История версий: [22]

  • 1.0: выпущен в сентябре 1992 г. [23]
  • 2.0: с. 1994 г.
  • 2,5
  • 3.0: с. В 1995 г. значительный вклад в ODBC 3.0 внесли Джон Гудсон из Intersolv, а также Фрэнк Пеллоу и Пол Коттон из IBM [24]
  • 3.5: с. 1997 г.
  • 3.8: с. 2009 г., с Windows 7 [25]
  • 4.0: Разработка объявлена ​​в июне 2016 г. [26] с первой реализацией с SQL Server 2017, выпущенным в сентябре 2017 г., и дополнительными драйверами для настольных ПК в конце 2018 г. [27] Окончательная спецификация на Github

Драйверы и менеджеры [ править ]

Драйверы [ править ]

ODBC основан на модели драйвера устройства , где драйвер инкапсулирует логику, необходимую для преобразования стандартного набора команд и функций в конкретные вызовы, требуемые базовой системой. Например, драйвер принтера предоставляет стандартный набор команд печати, API, приложениям, использующим систему печати. Вызовы этих API-интерфейсов преобразуются драйвером в формат, используемый фактическим оборудованием, например PostScript или PCL .

В случае ODBC драйверы включают в себя множество функций, которые можно разбить на несколько широких категорий. Один набор функций в первую очередь связан с поиском, подключением и отключением от СУБД, с которой общается драйвер. Второй набор используется для отправки команд SQL из системы ODBC в СУБД, преобразования или интерпретации любых команд, которые не поддерживаются внутренне. Например, СУБД, не поддерживающая курсоры, может эмулировать эту функциональность в драйвере. Наконец, другой набор команд, в основном используемых внутри компании, используется для преобразования данных из внутренних форматов СУБД в набор стандартизованных форматов ODBC, основанных на форматах языка C.

Драйвер ODBC позволяет ODBC-совместимому приложению использовать источник данных , обычно СУБД. Существуют некоторые драйверы, не относящиеся к СУБД, для таких источников данных, как файлы CSV , путем реализации небольшой СУБД внутри самого драйвера. Драйверы ODBC существуют для большинства СУБД, включая Oracle , PostgreSQL , MySQL , Microsoft SQL Server (но не для версии Compact aka CE ), Sybase ASE , SAP HANA [28] [29] и DB2.. Поскольку разные технологии имеют разные возможности, большинство драйверов ODBC не реализуют всех функций, определенных в стандарте ODBC. Некоторые драйверы предлагают дополнительные функции, не определенные стандартом.

Диспетчер драйверов [ править ]

Драйверы устройств обычно перечисляются, настраиваются и управляются отдельным уровнем диспетчера, который может предоставлять дополнительные функции. Например, системы печати часто включают функциональные возможности для обеспечения функции буферизации поверх драйверов, обеспечивая буферизацию печати для любого поддерживаемого принтера.

В ODBC диспетчер драйверов (DM) предоставляет эти функции. [30] DM может перечислить установленные драйверы и представить их в виде списка, часто в форме графического интерфейса пользователя.

Но более важным для работы системы ODBC является концепция имени источника данных (DSN) DM . DSN собирают дополнительную информацию, необходимую для подключения к определенному источнику данных, по сравнению с самой СУБД. Например, тот же драйвер MySQL можно использовать для подключения к любому серверу MySQL, но информация о подключении для подключения к локальному частному серверу отличается от информации, необходимой для подключения к общедоступному серверу, размещенному в Интернете. DSN хранит эту информацию в стандартизированном формате, а DM предоставляет ее драйверу во время запросов на соединение. DM также включает функциональные возможности для представления списка DSN с использованием удобочитаемых имен и их выбора во время выполнения для подключения к различным ресурсам.

DM также включает возможность сохранять частично полные DSN с кодом и логикой, чтобы запрашивать у пользователя любую недостающую информацию во время выполнения. Например, DSN можно создать без необходимого пароля. Когда приложение ODBC пытается подключиться к СУБД с использованием этого DSN, система приостанавливает работу и просит пользователя ввести пароль перед продолжением. Это освобождает разработчика приложения от необходимости создавать такой код, а также от необходимости знать, какие вопросы задавать. Все это включено в драйвер и DSN.

Конфигурации моста [ править ]

Мост представляет собой особый вид драйвера: драйвер , который использует другую технологию на основе драйверов.

Мосты ODBC-JDBC (ODBC-JDBC) [ править ]

Мост ODBC-JDBC состоит из драйвера ODBC, который использует службы драйвера JDBC для подключения к базе данных. Этот драйвер переводит вызовы функций ODBC в вызовы методов JDBC. Программисты обычно используют такой мост, когда у них нет драйвера ODBC для какой-либо базы данных, но есть доступ к драйверу JDBC. Примеры: OpenLink ODBC-JDBC мост , SequeLink ODBC-JDBC Bridge .

Мосты JDBC-ODBC (JDBC-ODBC) [ править ]

Мост JDBC-ODBC состоит из драйвера JDBC, который использует драйвер ODBC для подключения к целевой базе данных. Этот драйвер переводит вызовы методов JDBC в вызовы функций ODBC. Программисты обычно используют такой мост, когда в данной базе данных отсутствует драйвер JDBC, но она доступна через драйвер ODBC. Sun Microsystems включила один такой мост в JVM , но рассматривала его как временную меру, пока существовало несколько драйверов JDBC (встроенный мост JDBC-ODBC был исключен из JVM в Java 8 [31] ). Sun никогда не планировала свой мост для производственных сред и обычно не рекомендовала его использовать. По состоянию на 2008 г.Независимые поставщики доступа к данным поставляют мосты JDBC-ODBC, которые поддерживают текущие стандарты для обоих механизмов и намного превосходят встроенную JVM. [ Править ] Примеры: OpenLink JDBC-ODBC Bridge , SequeLink JDBC-ODBC Bridge .

Мосты OLE DB-ODBC [ править ]

Мост OLE DB-ODBC состоит из поставщика OLE DB, который использует службы драйвера ODBC для подключения к целевой базе данных. Этот провайдер переводит вызовы методов OLE DB в вызовы функций ODBC. Программисты обычно используют такой мост, когда в данной базе данных отсутствует поставщик OLE DB, но она доступна через драйвер ODBC. Microsoft поставляет MSDASQL.DLL как часть пакета системных компонентов MDAC вместе с другими драйверами баз данных, чтобы упростить разработку на языках, поддерживающих COM (например, Visual Basic ). Третьи стороны также разработали такое программное обеспечение, в частности программное обеспечение OpenLink, чей 64-разрядный поставщик OLE DB для источников данных ODBC заполнил пробел, когда Microsoft изначально не рекомендовала этот мост для своей 64-разрядной ОС. [32] (Позднее Microsoft уступила, и 64-битная Windows, начиная с Windows Server 2008 и Windows Vista SP1 , поставлялась с 64-битной версией MSDASQL.) Примеры: OpenLink OLEDB-ODBC Bridge , SequeLink OLEDB-ODBC Bridge .

Мосты между ADO.NET и ODBC [ править ]

Мост ADO.NET-ODBC состоит из поставщика ADO.NET, который использует службы драйвера ODBC для подключения к целевой базе данных. Этот провайдер переводит вызовы методов ADO.NET в вызовы функций ODBC. Программисты обычно используют такой мост, когда в данной базе данных отсутствует поставщик ADO.NET, но она доступна через драйвер ODBC. Microsoft поставляет один как часть пакета системных компонентов MDAC вместе с другими драйверами базы данных, чтобы упростить разработку на C # . Третьи стороны тоже разработали такие. Примеры: OpenLink ADO.NET-ODBC Bridge , SequeLink ADO.NET-ODBC Bridge .

См. Также [ править ]

  • Доступ к данным GNU
  • Подключение к базе данных Java (JDBC)
  • Архитектура открытых служб Windows
  • Администратор ODBC

Ссылки [ править ]

Библиография
  • Гейгер, Кайл (1995). Внутри ODBC . Microsoft Press. ISBN 9781556158155.
Цитаты
  1. ^ МакГлинн, Эван (1988), Blueprint Lets 1-2-3 Access Outside Data " , InfoWorld , том 10, № 14, 4 апреля 1988 г., стр. 1, 69
  2. ^ а б Гейгер 1995 , стр. 65.
  3. Перейти ↑ Geiger 1995 , p. 86-87.
  4. Перейти ↑ Geiger 1995 , p. 56.
  5. Перейти ↑ Geiger 1995 , p. 106.
  6. Перейти ↑ Geiger 1995 , p. 165.
  7. ^ а б Гейгер 1995 , стр. 186-187.
  8. ^ ISO / IEC 9075-3 - Информационные технологии - Языки баз данных - SQL - Часть 3: Интерфейс уровня вызовов (SQL / CLI)
  9. Перейти ↑ Geiger 1995 , p. 203.
  10. ^ Хариндранатх, G; Йоже Зупанчич (2001). Новые перспективы развития информационных систем: теория, методы, практика . Springer. п. 451. ISBN. 978-0-306-47251-0. Проверено 28 июля 2010 . Первые драйверы ODBC […] использовали процессор запросов SIMBA, который транслировал вызовы в вызовы Microsoft Jet ISAM и отправлял вызовы соответствующему драйверу ISAM для доступа к бэкэнду […]
  11. ^ "Linux / UNIX ODBC - Что такое ODBC?" .
  12. ^ "Наша история" , Simba Technologies
  13. ^ Idehen, Кингсли уйи (октябрь 1994). «ODBC и прогресс V7.2d» . Базы данных группы новостей Usenet . Проверено 13 декабря 2013 года .
  14. ^ Idehen, Кингсли уйи (1995-07-18). «Нужен драйвер ODBC / Ingres для DEC OSF / 1» . Группа новостей Usenet comp.databases.oracle . Проверено 13 декабря 2013 года .
  15. ^ Сиппл, Роджер (1996) "Интерфейс уровня вызовов SQL Access Group" , доктор Доббс, 1 февраля 1996 г.
  16. ^ «Сходства и различия между ODBC и CLI» , документация InfoSphere Classic, IBM, 26 сентября 2008 г.
  17. ^ [1]
  18. ^ «Объявление о новом выпуске драйвера OLE DB для SQL Server» .
  19. ^ Андерсон, Эндрю (2003-06-20). «Открытое подключение к базам данных в Jaguar» . O'Reilly MacDevCenter.com . O'Reilly Media, Inc . Проверено 13 декабря 2013 года .
  20. ^ Продавцы, Деннис (2001-07-17). «Обновление ODBC SDK для Mac OS Classic, Mac OS X» . MacWorld . IDG Consumer & SMB . Проверено 13 декабря 2013 года .
  21. ^ Вернер, Кристиан (2018) «Драйвер SQLite ODBC». Архивировано 26 июня 2014 г. на Wayback Machine , 24 февраля 2018 г.
  22. ^ "Версии ODBC" . Linux / UNIX ODBC . Easysoft . Проверено 27 октября 2009 .
  23. ^ Антал, Тибериу Александру. «Доступ к базе данных Oracle с помощью JDBC» (PDF) . Клуж-Напока: Технический университет Клуж-Напока. п. 2. Архивировано из оригинального (PDF) 22.07.2011 . Проверено 27 октября 2009 . ODBC 1.0 был выпущен в сентябре 1992 г.
  24. ^ Корпорация Microsoft. Справочник программиста Microsoft ODBC 3.0 и руководство по SDK, том 1. Microsoft Press. Февраль 1997 г. ( ISBN 9781572315167 ). 
  25. ^ «Что нового в ODBC 3.8» . Microsoft . Проверено 13 января 2010 . Windows 7 включает обновленную версию ODBC, ODBC 3.8.
  26. ^ Rukmangathan, KrishnaKumar (2016-06-07). «Новый выпуск ODBC для современных хранилищ данных» . Блог Microsoft Data Access / SQL BI Technologies . Microsoft . Проверено 3 января 2017 . Спустя более 15 лет с момента последнего выпуска Microsoft рассматривает возможность обновления спецификации Open Data Base Connectivity (ODBC).
  27. ^ https://docs.microsoft.com/cs-cz/sql/odbc/microsoft/history-of-the-desktop-database-drivers?view=sql-server-ver15
  28. ^ «Свойства системы SAP HANA» . DB-Двигатели . Проверено 28 марта 2016 .
  29. ^ «Подключение к SAP HANA через ODBC - Руководство разработчика SAP HANA для SAP HANA Studio - Библиотека SAP» . help.sap.com . Проверено 28 марта 2016 .
  30. ^ Sybase. «Введение в ODBC» . infocenter.sybase.com . Sybase . Проверено 8 октября 2011 года .
  31. ^ "Java JDBC API" . docs.oracle.com . Проверено 18 декабря 2018 .
  32. ^ Microsoft , «Дорожная карта технологий доступа к данным», устаревшие компоненты MDAC, Microsoft «Руководство программиста ADO» Приложение A: поставщики, поставщик Microsoft OLE DB для ODBC , получено 30 июля 2005 г. Архивировано 5 октября 2001 г. на Wayback Machine

Внешние ссылки [ править ]

  • Обзор Microsoft ODBC
  • Администрирование OS400 и i5OS ODBC
  • Презентационные слайды с сайта www.roth.net
  • Статья об истории Microsoft ODBC и API доступа к данным .