✖
~~~~~~~~~~~~~~~~~~~~ Arc.Ask3.Ru ~~~~~~~~~~~~~~~~~~~~~ 
Номер скриншота №:
✰ 39820C6A29EB3993E436BBFE6051DAC6__1708671240 ✰
Заголовок документа оригинал.:
✰ Open Database Connectivity - Wikipedia ✰
Заголовок документа перевод.:
✰ Возможность подключения к открытой базе данных — Википедия ✰
Снимок документа находящегося по адресу (URL):
✰ https://en.wikipedia.org/wiki/Open_Database_Connectivity ✰
Адрес хранения снимка оригинал (URL):
✰ https://arc.ask3.ru/arc/aa/39/c6/39820c6a29eb3993e436bbfe6051dac6.html ✰
Адрес хранения снимка перевод (URL):
✰ https://arc.ask3.ru/arc/aa/39/c6/39820c6a29eb3993e436bbfe6051dac6__translat.html ✰
Дата и время сохранения документа:
✰ 21.06.2024 21:09:12 (GMT+3, MSK) ✰
Дата и время изменения документа (по данным источника):
✰ 23 February 2024, at 09:54 (UTC). ✰ 

~~~~~~~~~~~~~~~~~~~~~~ Ask3.Ru ~~~~~~~~~~~~~~~~~~~~~~ 
Сервисы Ask3.ru: 
 Архив документов (Снимки документов, в формате HTML, PDF, PNG - подписанные ЭЦП, доказывающие существование документа в момент подписи. Перевод сохраненных документов на русский язык.) 
✰ https://arc.ask3.ru ✰
 Ответы на вопросы (Сервис ответов на вопросы, в основном, научной направленности) 
✰ https://ask3.ru/answer2question ✰
 Товарный сопоставитель (Сервис сравнения и выбора товаров) ✰✰
✰ https://ask3.ru/product2collation ✰
 Партнеры 
✰ https://comrades.ask3.ru ✰


Совет. Чтобы искать на странице, нажмите Ctrl+F или ⌘-F (для MacOS) и введите запрос в поле поиска.
Arc.Ask3.ru: далее начало оригинального документа

Возможность подключения к открытой базе данных — Википедия Jump to content

Возможность подключения к открытой базе данных

Из Википедии, бесплатной энциклопедии

В вычислительной технике 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 сохранил несколько функций, которые были удалены в рамках CLI. Позже полный ODBC был перенесен обратно на эти платформы и стал стандартом де-факто, значительно более известным, чем CLI. CLI остается похожим на ODBC, и приложения можно переносить с одной платформы на другую с небольшими изменениями.

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

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

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

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

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

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

попытки Ранние ​ ​

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

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

Одним из первых примеров такой системы была Lotus Development от 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. Большая часть системы была основана на системе DB-Library от Sybase, с удаленными разделами, специфичными для Sybase, и несколькими дополнениями для поддержки других платформ. [3] DB-Library помог общеотраслевой переход от библиотечных систем, тесно связанных с определенным языком, к библиотечным системам, которые предоставлялись операционной системой и требовали, чтобы языки на этой платформе соответствовали ее стандартам. Это означало, что одну библиотеку можно было использовать (потенциально) с любым языком программирования на данной платформе.

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

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

В 1988 году несколько поставщиков, в основном из сообществ Unix и баз данных, сформировали группу доступа SQL (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. Также в этот период было официально принято название «Интерфейс уровня вызова». [7] В 1995 году SQL/CLI стал частью международного стандарта SQL ISO/IEC 9075-3. [8] Сама SAG была передана группе X/Open в 1996 году и со временем стала частью The Open Group Common Application Environment .

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

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

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

Усилия SAG по стандартизации предоставили Microsoft возможность адаптировать свою систему Jet к новому стандарту CLI. Это не только сделает Windows лучшей платформой для разработки CLI, но и позволит пользователям использовать 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 во внутренний формат Jet на основе C, а затем передавались драйверу для преобразования обратно в вызовы SQL для базы данных. Digital Equipment и Oracle также заключили с Simba Technologies контракт на разработку драйверов для своих баз данных. [12]

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

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

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

Поскольку Microsoft отвлеклась от непосредственной работы над ODBC, область Unix все больше охватывала его. Этому способствовали два изменения на рынке: появление графических пользовательских интерфейсов (GUI), таких как GNOME , которые обеспечивали необходимость доступа к этим источникам в нетекстовой форме, и появление с открытым программным обеспечением систем баз данных , таких как PostgreSQL и MySQL , первоначально Юникс. Более позднее принятие ODBC компанией Apple для использования стандартного 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). версию ODBC для языка программирования Java вместо C. Во многих отношениях JDBC можно рассматривать как JDBC-ODBC Мосты позволяют программам на основе Java получать доступ к источникам данных через драйверы ODBC на платформах, на которых отсутствует собственный драйвер JDBC, хотя сейчас они встречаются относительно редко. И наоборот, мосты ODBC-JDBC позволяют программам на основе C получать доступ к источникам данных через драйверы JDBC на платформах или из баз данных, в которых отсутствуют подходящие драйверы ODBC.

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

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

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

Спецификации ODBC [22] [ редактировать ]

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

Драйверы баз данных настольных компьютеров [27] [ редактировать ]

  • 1.0 (1993–08): использовался процессор запросов SIMBA, созданный PageAhead Software.
  • 2.0 (1994–12): используется с ODBC 2.0.
  • 3.0 (1995–10): поддерживает Windows 95 и рабочую станцию ​​Windows NT или NT Server 3.51. В этот выпуск были включены только 32-битные драйверы.
  • 3.5 (1996–10): поддерживает двухбайтовый набор символов (DBCS) и позволяет использовать имена источников данных файлов (DSN). Драйвер Microsoft Access был выпущен в версии RISC для использования на платформах Alpha для операционных систем Windows 95/98 и Windows NT 3.51 и более поздних версий.
  • 4.0 (конец 1998 г.): поддержка формата Unicode Microsoft Jet Engine, а также совместимость с форматом ANSI более ранних версий.

Водители и менеджеры [ править ]

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

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

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

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

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

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

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

Но более важным для работы системы ODBC является концепция DM имени источника данных (DSN). 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 Bridge , 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-to-ODBC [ править ]

Мост OLE DB-ODBC состоит из поставщика OLE DB , который использует службы драйвера ODBC для подключения к целевой базе данных. Этот поставщик преобразует вызовы методов OLE DB в вызовы функций ODBC. Программисты обычно используют такой мост, когда у данной базы данных нет поставщика OLE DB, но она доступна через драйвер ODBC. Microsoft поставляет один из них, MSDASQL.DLL, как часть MDAC пакета системных компонентов вместе с другими драйверами баз данных, чтобы упростить разработку на языках, поддерживающих COM (например, Visual Basic ). Третьи стороны также разработали такие технологии, в частности OpenLink Software, чей 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-to-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 .

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

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

Библиография
  • Гейгер, Кайл (1995). Внутри ODBC . Майкрософт Пресс. ISBN  9781556158155 .
Цитаты
  1. ^ МакГлинн, Эван (1988), Blueprint позволяет 1-2-3 получать доступ к внешним данным» , InfoWorld , том 10, № 14, 4 апреля 1988 г., стр. 1, 69
  2. ^ Перейти обратно: а б Гейгер 1995 , с. 65.
  3. ^ Гейгер 1995 , с. 86-87.
  4. ^ Гейгер 1995 , с. 56.
  5. ^ Гейгер 1995 , с. 106.
  6. ^ Гейгер 1995 , с. 165.
  7. ^ Перейти обратно: а б Гейгер 1995 , с. 186-187.
  8. ^ ISO/IEC 9075-3 – Информационные технологии – Языки баз данных – SQL – Часть 3: Интерфейс уровня вызовов (SQL/CLI)
  9. ^ Гейгер 1995 , с. 203.
  10. ^ Хариндранатх, Дж; Йоже Зупанчич (2001). Новые взгляды на развитие информационных систем: теория, методы и практика . Спрингер. п. 451. ИСБН  978-0-306-47251-0 . Проверено 28 июля 2010 г. Первые драйверы ODBC […] использовали процессор запросов SIMBA, который преобразовывал вызовы в вызовы Microsoft Jet ISAM и отправлял вызовы соответствующему драйверу ISAM для доступа к серверной части […]
  11. ^ «Linux/UNIX ODBC – Что такое ODBC?» .
  12. ^ «Наша история» , Simba Technologies.
  13. ^ Идехен, Кингсли Уи (октябрь 1994 г.). «ODBC и прогресс V7.2d» . Группа новостей Usenet comp.databases . Проверено 13 декабря 2013 г.
  14. ^ Идехен, Кингсли Уи (18 июля 1995 г.). «Требуется драйвер ODBC/Ingres для DEC OSF/1» . Группа новостей Usenet comp.databases.oracle . Проверено 13 декабря 2013 г.
  15. ^ Сиппл, Роджер (1996) «Интерфейс уровня вызовов группы доступа SQL» , доктор Доббс, 1 февраля 1996 г.
  16. ^ «Сходства и различия между ODBC и CLI» , документация InfoSphere Classic, IBM, 26 сентября 2008 г.
  17. ^ «OLE DB и SQL Server: история, конец игры и немного «грязи» от Microsoft » . 25 сентября 2011 г.
  18. ^ «Анонсируем новый выпуск драйвера OLE DB для SQL Server» .
  19. ^ Андерсон, Эндрю (20 июня 2003 г.). «Подключение к открытой базе данных в Jaguar» . О'Рейли MacDevCenter.com . О'Рейли Медиа, Инк . Проверено 13 декабря 2013 г.
  20. ^ Селлерс, Деннис (17 июля 2001 г.). «Вышло обновление ODBC SDK для Mac OS Classic, Mac OS X» . МакВорлд . IDG для потребителей и малого и среднего бизнеса . Проверено 13 декабря 2013 г.
  21. ^ Вернер, Кристиан (2018) «Драйвер SQLite ODBC». Архивировано 26 июня 2014 г. на Wayback Machine , 24 февраля 2018 г.
  22. ^ «Версии ODBC» . Linux/UNIX ODBC . Изисофт . Проверено 27 октября 2009 г.
  23. ^ Антал, Тибериу Александру. «Доступ к базе данных Oracle с помощью JDBC» (PDF) . Клуж-Напока: Технический университет Клуж-Напока. п. 2. Архивировано из оригинала (PDF) 22 июля 2011 г. Проверено 27 октября 2009 г. ODBC 1.0 был выпущен в сентябре 1992 года.
  24. ^ Корпорация Microsoft. Справочник программиста Microsoft ODBC 3.0 и руководство по SDK, том 1. Microsoft Press. Февраль 1997 года. ( ISBN   9781572315167 )
  25. ^ «Что нового в ODBC 3.8» . Майкрософт . Проверено 13 января 2010 г. Windows 7 включает обновленную версию ODBC — ODBC 3.8.
  26. ^ Рукмангатан, Кришнакумар (7 июня 2016 г.). «Новый выпуск ODBC для современных хранилищ данных» . Доступ к данным Microsoft / Блог о технологиях SQL BI . Майкрософт . Проверено 3 января 2017 г. Спустя более 15 лет с момента последнего выпуска Microsoft рассматривает возможность обновления спецификации Open Data Base Connectivity (ODBC).
  27. ^ «История драйверов баз данных настольных компьютеров» .
  28. ^ «Свойства системы SAP HANA» . DB-двигатели . Проверено 28 марта 2016 г.
  29. ^ «Подключение к SAP HANA через ODBC — Руководство разработчика SAP HANA для SAP HANA Studio — Библиотека SAP» . help.sap.com . Проверено 28 марта 2016 г.
  30. ^ Сибаза. «Введение в ODBC» . infocenter.sybase.com . Сибаза . Проверено 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.

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

Retrieved from "https://en.wikipedia.org/w/index.php?title=Open_Database_Connectivity&oldid=1209737551"
Arc.Ask3.Ru: конец оригинального документа.
Arc.Ask3.Ru
Номер скриншота №: 39820C6A29EB3993E436BBFE6051DAC6__1708671240
URL1:https://en.wikipedia.org/wiki/Open_Database_Connectivity
Заголовок, (Title) документа по адресу, URL1:
Open Database Connectivity - Wikipedia
Данный printscreen веб страницы (снимок веб страницы, скриншот веб страницы), визуально-программная копия документа расположенного по адресу URL1 и сохраненная в файл, имеет: квалифицированную, усовершенствованную (подтверждены: метки времени, валидность сертификата), открепленную ЭЦП (приложена к данному файлу), что может быть использовано для подтверждения содержания и факта существования документа в этот момент времени. Права на данный скриншот принадлежат администрации Ask3.ru, использование в качестве доказательства только с письменного разрешения правообладателя скриншота. Администрация Ask3.ru не несет ответственности за информацию размещенную на данном скриншоте. Права на прочие зарегистрированные элементы любого права, изображенные на снимках принадлежат их владельцам. Качество перевода предоставляется как есть, любые претензии не могут быть предъявлены. Если вы не согласны с любым пунктом перечисленным выше, немедленно покиньте данный сайт. В случае нарушения любого пункта перечисленного выше, штраф 55! (Пятьдесят пять факториал, денежную единицу можете выбрать самостоятельно, выплаичвается товарами в течение 7 дней с момента нарушения.)