Odbc driver что такое

Обновлено: 02.07.2024

Часто приходится слышать о том, что многие не понимают различия между технологиями ODBC и OLE DB. Иногда между ними даже ставят знак равенства. В статье рассматривается сходство этих технологий и их различие.

На примере баз данных Firebird и InterBase даны рекомендации, которые помогут вам при выборе средства доступа.

Управляющие последовательности ODBC (ODBC Escape Sequences)

Развитие языка SQL сделало его реализации в различных базах данных несовместимыми между собой. Для решения проблемы совместимости были предложены управляющие последовательности ODBC (ODBC Escape Sequences). Они позволили писать SQL запросы, которые были бы совместимы с большинством баз данных.

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

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

Пример кода

Тестовое приложение, которое показывает, как считывать метаданные классификации данных. В Windows его можно скомпилировать с помощью cl /MD dataclassification.c /I (directory of msodbcsql.h) /link odbc32.lib и выполнить с использованием строки подключения и SQL-запроса (который возвращает классифицированные столбцы) в качестве параметров:

Источники данных ODBC

OLE DB, в отличие от ODBC, является объектно-ориентированным API, основанным на COM-интерфейсах.

OLE DB провайдеры могут работать не только с реляционными базами данных, но и с любой другой информацией которую можно представить в табличном виде. Например: OLE DB провайдер для служб каталогов или Jet OLE DB провайдер, позволяющий извлекать данные из Excel и Outlook.

В OLE DB можно работать и с ODBC драйвером при помощи специального провайдера (OLE DB Provider for ODBC drivers), который умеет подключаться к источникам данных ODBC. Данная схема помогала в случае отсутствия OLE DB провайдера для конкретной базы данных. На сегодняшний день поддержка этого драйвера прекращена.

Содержание

Источники данных OLE DB

Для подключения через OLE DB не требуется регистрация источника данных в системе, как это принято в ODBC. Вся информация хранится либо в файлах с расширением udl, либо указывается непосредственно в строке подключения.

Для редактирования подключения OLE DB с расширением udl ассоциирован редактор связей с данными Data Link. Он поддерживает расширенную настройку провайдера данных за счет включения в свой интерфейс дополнительных страниц, о которых ему сообщает выбранный OLE DB провайдер.

Чтобы запустить редактор Data Link создайте пустой файл с расширением udl и запустите его на выполнение.

Business Intelligence

В состав SQL Server входят три средства Business Intelligence:

ADO и DAO

Библиотека ADO поддерживается следующими средствами:

  • в Visual Studio: Visual C++ и Visual Basic;
  • Microsoft Office, Visual Basic For Applications.
  • Скриптовые языки VBcript, JavaScript, WSH
  • Остальные, поддерживающие COM.

Драйверы на основе СУБД

драйверы на основе субд используются с такими источниками данных, как Oracle или SQL Server, которые предоставляют автономное ядро субд для использования драйвером. Эти драйверы обращаются к физическим данным через автономный модуль. то есть они отправляют SQLные инструкции и получают результаты из подсистемы.

Поскольку драйверы на основе СУБД используют существующее ядро СУБД, обычно проще писать, чем драйверы на основе файлов. Несмотря на то, что драйвер на основе СУБД можно легко реализовать путем преобразования вызовов ODBC в собственные вызовы API, это приводит к более медленному драйверу. Лучшим способом реализации драйвера на основе СУБД является использование базового протокола потока данных, который обычно работает в собственном API. например, драйвер SQL Server должен использовать TDS (протокол потока данных для SQL Server), а не библиотеку DB (собственный API для SQL Server). Исключением из этого правила является то, что ODBC является собственным API. Например, Ватком SQL — это автономный модуль, который находится на том же компьютере, что и приложение, и загружается непосредственно в качестве драйвера.

Драйверы на основе СУБД действуют как клиент в конфигурации клиента или сервера, где источник данных выступает в качестве сервера. В большинстве случаев клиент (драйвер) и сервер (источник данных) находятся на разных компьютерах, хотя они могут находиться на одном компьютере с многозадачной операционной системой. Третья возможность — это шлюз, который располагается между драйвером и источником данных. Шлюз — это часть программного обеспечения, которая приводит к тому, что одна СУБД выглядит как другая. например, приложения, написанные для использования SQL Server, могут также получать доступ к данным DB2 через шлюз Micro деЦисионваре DB2. Этот продукт приводит к тому, что DB2 будет выглядеть так, как SQL Server.

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

Microsoft MS SQL Server

SQL Server позволяет обращаться из Transact SQL к базам данных других серверов, включая Firebird и InterBase через технологию Linked Server.

Linked Server взаимодействует только с OLE DB провайдерами и не поддерживает ODBC дравейра.

Что такое ODBC драйвер?

ODBC драйвера были одной из первых попыток Microsoft стандартизировать механизмы доступа к данным.

ODBC драйвер представлял собой реализацию ODBC API на языке C. Вызовы ODBC API транслировались на API конкретной базы данных.

Интеграция с Microsoft Office

Средства Microsoft Office поддерживают загрузку данных и через OLE DB и через ODBC. Полноценное использование всех офисных средств управления данными зависит от возможностей конкретных OLE DB провайдеров и ODBC драйверов.

Для пользователей Firebird и InterBase такая поддержка есть.

Формат

Синтаксис SQLGetDescField имеет следующий вид:

ValuePtr
[Выход] Выходной буфер.

StringLengthPtr [Выход] Указатель на буфер, в котором будет возвращаться общее число байтов, доступных для получения из параметра ValuePtr.

Если размер буфера неизвестен, его можно определить путем вызова строки SQLGetDescField со значением NULL для параметра ValuePtr и проверки значения StringLengthPtr.

Если сведения о классификации данных недоступны, будет возвращена ошибка Недопустимое поле дескриптора.

При успешном вызове SQLGetDescField буфер, на который указывает параметр ValuePtr, будет содержать следующие данные:

nn nn [n sensitivitylabels] tt tt [t informationtypes] cc cc [c columnsensitivitys]

Значения nn nn , tt tt и cc cc являются многобайтовыми целыми числами, которые хранятся с наименее значимым байтом в нижнем адресе.

Значения sensitivitylabel и informationtype имеют формат:

nn [n bytes name] ii [i bytes id]

Значение columnsensitivity имеет формат:

nn nn [n sensitivityprops]

Для каждого столбца (c) имеется n длиной 4 байта sensitivityprops .

s — индекс для массива sensitivitylabels (значение FF FF , если он не помечен).

t — индекс для массива informationtypes (значение FF FF , если он не помечен).

Формат данных может выражаться в виде следующих псевдоструктур:

Поддерживаемая версия

Microsoft ODBC Driver 17.2 позволяет получить сведения о классификации данных с помощью SQLGetDescField , если FieldIdentifier имеет значение SQL_CA_SS_DATA_CLASSIFICATION (1237).

Начиная с версии Microsoft ODBC Driver 17.4.1.1 можно извлекать версию классификации данных, поддерживаемую сервером, с помощью SQLGetDescField и идентификатора поля SQL_CA_SS_DATA_CLASSIFICATION_VERSION (1238). В версии 17.4.1.1 для поддерживаемой версии классификации данных указано значение "2".

Начиная с версии 17.4.2.1 поддерживается версия классификации данных по умолчанию, которая имеет значение "1" и является версией, которую драйвер указывает SQL Server как поддерживаемую. Новый атрибут подключения SQL_COPT_SS_DATACLASSIFICATION_VERSION (1400) позволяет приложению изменять поддерживаемую версию классификации данных со значения "1" до максимальной поддерживаемой версии.

Чтобы задать версию, этот вызов требуется выполнить сразу перед вызовом SQLConnect или SQLDriverConnect:

Значение поддерживаемой в настоящее время версии классификации данных можно получить с помощью вызова SQLGetConnectAttr:

Дополнительная информация с сайта IBProvider

Классификация данных

Для управления конфиденциальными данными в SQL Server и Azure SQL Server появилась возможность предоставлять столбцы базы данных с конфиденциальными метаданными, что позволяет клиентскому приложению обрабатывать различные типы конфиденциальных данных (например, данные о состоянии здоровья, финансовые данные и т. д.) в соответствии с политикой защиты данных.

Дополнительные сведения о назначении классификации столбцам см. в статье Обнаружение и классификация данных SQL.

Microsoft ODBC Driver 17.2 позволяет получать эти метаданные через SQLGetDescField, используя идентификатор поля SQL_CA_SS_DATA_CLASSIFICATION.

Драйвера

Драйверы — это библиотеки, которые реализуют функции в API ODBC. Каждый специфичен для конкретной СУБД. Например, драйвер для Oracle не может напрямую обращаться к данным в СУБД с Informix. Драйверы раскрывают возможности базовых СУБД. Они не требуются для реализации возможностей, не поддерживаемых в СУБД. Если базовая СУБД не поддерживает внешние соединения, то драйвер не нужен. Единственным серьезным является то, что драйверы для СУБД, которые не имеют автономных механизмов БД, таких как Xbase, должен реализовать механизм СУБД, поддерживающий по крайней мере минимальный объем SQL [Источник 4] .

Задачи драйвера

Определенные задачи, выполняемые драйверами включают:

  • Подключение и отключение от источника данных.
  • Проверка ошибки функций, не проверяется диспетчером драйверов.
  • Запуск транзакций. Этот процесс прозрачен для приложения.
  • Отправка инструкций SQL к источнику данных для выполнения. Драйвер должен изменить ODBC SQL в конкретный СУБДSQL.
  • Отправка и извлечение данных из источника данных, в том числе преобразование типов данных, определенной в приложении.
  • Отображение ошибок, связанных с СУБД в ODBC SQLSTATE.

Архитектура драйвера

Файловый драйвер

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

СУБД драйверы

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

ODBC Firebird, ODBC InterBase или все же OLE DB?

ODBC драйвера

ODBC драйвера Easysoft распространяются отдельно для Firebird и отдельно для InterBase:

На сайте Easysoft достаточно внушительный список ODBC драйверов, но нет информации о дате последних обновлений драйверов для Firebird и InterBase. Судя по номерам поддерживаемых версий, изменения происходили достаточно давно.

Для того чтобы скачать эти драйвера, необходимо зарегистрироваться на сайте EasySoft.

OLE DB

В состав решения входят 2 OLE DB провайдера. Подробнее о назначении каждого читайте здесь

ODBC (Open Database Connectivity)

ODBC (Open DataBase Connectivity) — широко применяемый прикладной программный интерфейс (API) для доступа к БД. Основан на спецификациях Call-Level Interface из Open Group и ISO/IEC для функций API БД и использует SQL [Источник 1] .

Заключение

На мой взгляд, выбор технологии доступа для Firebird и InterBase очевиден, но, несмотря на это каждый месяц посетители поисковых систем ищут магические ODBC Firebird driver и ODBC InterBase driver для создания новых приложений.

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

Преимущества использования стандартных интерфейсов

    Можно выделить следующие преимущества такого подхода:
  • Независимость клиентского приложения от деталей реализации источника данных.
  • Легкий переход между версиями серверов баз данных.
  • Возможность работы приложения с несколькими серверами баз данных.
  • Поддержка со стороны большого числа средств разработки.

Идея состоит в том, что разработчикам легче реализовать один стандартный интерфейс, чем поддерживать множество базы данных с различным API.

Приложения

Приложения — это программа, которая вызывает API ODBC для доступа к данным. Большинство приложений делятся на три категории [Источник 3] :

Универсальные приложения

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

Вертикальные приложения

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

Приложение использует ODBC таким образом, что приложение не привязано к любой из СУБД, несмотря на то, что он может быть привязан к ограниченному числу СУБД, которые предоставляют аналогичные функциональные возможности. Таким образом, разработчик приложения может продавать приложение независимо от СУБД. Вертикальные приложения совместимы при разработке, но иногда модифицируются, чтобы включить несовместимый код, когда клиент выбрал СУБД.

Пользовательские приложения

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

Число задач является общим для всех приложений, независимо от того, как они используют ODBC. В общем, они во многом определяют поток любого приложения ODBC. Например:

  • Выбор источника данных и подключение к нему.
  • Отправка инструкции SQL для выполнения.
  • Извлечение результатов (если таковые имеются).
  • Ошибки обработки.
  • Фиксация или откат транзакции, заключив инструкцию SQL.
  • Отключение от источника данных.

Архитектура


Рисунок 1 – Архитектура ODBC

  1. Приложения
  2. Диспетчер драйверов
  3. Драйвер
  4. Источник данных

На рисунке 1 можно увидеть архитектуру ODBC.

Читайте также: