Программное управление источниками данных ODBC
Тема нашего сегодняшнего разговора — ODBC. Если вы хоть раз писали СУБД (системы управления базами данных), то вам, наверное, знакома эта аббревиатура. Расшифровывается ODBC как Open DataBase Connectivity (вольный перевод — открытая система связи с базами данных). Open (открытая) в данном случае означает «расширяемая», «легко наращиваемая», «открытая для модификаций». Вы сами это поймете, если посмотрите на архитектуру построения ODBC:
Как легко заметить, она действительно легко наращиваемая. Для добавления нового типа БД нужно лишь написать драйвер и зарегистрировать его. Еще одно преимущество, вытекающее из такого построения ODBC — пользовательское приложение общается с физической БД через менеджер драйверов, фактически ничего не зная о типе используемой БД (общение менеджера драйверов и самих драйверов более менее стандартно, так что с точки зрения пользователя все источники данных обладают практически одинаковыми свойствами). Таким образом, вы легко можете поменять физический тип базы данных, а приложение даже не узнает об этом (конечно, существуют исключения из-за особенностей поддержки языка SQL различными типами БД, но они несущественны).
Физически ODBC представляет собой набор динамических библиотек DLL, которые обслуживают подключение и работу с конкретным типом базы данных.При запросе на подключение к определенной, заранее описанной базе «активизируется» определенная DLL — драйвер этого типа БД. Обращение к определенной базе данных происходит по имени так называемого источника данных ODBC (или DSN — data source name). Можно представить DSN как своего рода объявление БД на данном компьютере, причем DSN может быть пользовательским, т.е. находится в области видимости только одного польователя, в сеансе которого был создан этот DSN, и системным, т.е. видимым всеми пользователями данного компьютера.
Управление источниками данных ODBC (да и вообще настройкой всей системы ODBC) осуществляется с помощью специальной программы — ODBC-администратора. Давайте разберем, где его можно найти в различных версиях Windows:
— Windows 9х — сам исполняемый файл odbcad32.exe лежит в каталоге Windows\System. Запускать его можно напрямую либо через Панель управления (значок «Источники данных ODBC (32-бит)»). Если на компьютере установлен BDE, запустите администратор BDE и из меню Object выберите пункт ODBC Administrator.
— Windows 2000 — исполняемый файл odbcad32.exe лежит в каталоге WinNT\System32, а запускать его можно через Панель управления -> Администрирование -> Источники данных ODBC. К сожалению, у меня нет возможности проверить, как с ODBC в NT3.51 / 4 — не думаю, что там ребята из Microsoft сильно его спрятали.
Почему ODBC?
Ведь есть же BDE, скажете вы. Да, возможно вы правы. Однако здесь есть «но». У обоих движков есть свои преимущества и недостатки. ODBC намного лучше работает с «родными, от Microsoft» источниками данных продуктов Microsoft Office — типа Access, Excel, MS SQL Server (вообще-то из-за Access я и затеял всю эту писанину). Кроме того, в стандартный дистрибутив BDE, который можно на каждом шагу найти в Интернете, я что-то ни разу не встречал SQL Links, впрочем, как я ни разу не встречал и отдельного дистрибутива SQL Links. А именно после установки SQL Links в BDE появлется возможность создавать алиасы к Access, MS SQL Server, Oracle и др. типам баз данных. Устанавливать же полную версию C++Builder или Delphi на компьютер пользователя может не каждый. А ODBC на «голой» машине уже содержит драйверы Access, Excel, FoxPro и SQL Server. В общем, для общего развития не помешает освоить и ODBC, тем более что access’овские базы, с которыми мы будем работать через ODBC, очень надежны (не в пример стандартным BDE’шным paradox’овым, у которых то и дело сыпятся индексы, а про такое поле как счетчик я вообще молчу), практически на любом компьютере пользователя установлен Office, что позволяет вносить коррективы «на месте», да и удобство всей базы в одном файле тоже иногда сказывается.
Фнукции, с которыми нам придется работать
Естественно, я не буду рассказывать обо всех функциях, с помощью которых можно сделать с ODBC все, что угодно. Поверьте, их очень много. Нам же для нашей практической задачи достаточно будет всего четырех:
1. Функция SQLDataSources возвращает список всех источников данных ODBC.
RETCODE SQLDataSources(HENV hEnv, UWORD fDirection, UCHAR * szDSN, SWORD cbDSNMax, SWORD *pcbDSN, UCHAR * szDescription, SWORD cbDescriptionMax, SWORD * pcbDescription );
- hEnv — хэндл, возвращаемый функцией SQLAllocEnv();
- fDirection — задает режим работы. Может принимать значения SQL_FETCH_FIRST — вернуть первую запись и SQL_FETCH_NEXT — вернуть следующую запись. Логика работы аналогична функциям FindFirst и FindNext (помните DOS?);
- szDSN — указатель на буфер длиной не менее cbDSNMax, куда будет записано имя источника данных;
- cbDSNMax — длина буфера szDSN;
- pcbDSN — указатель на целое, куда записывается реальная длина (не включая завершающий \0) принятого имени источника данных;
- szDescription — указатель на буфер длиной как минимум 255 символов, куда запистывается описание принятого источника данных;
- cbDescriptionMax — длина буфера szDescription;
- pcbDescripton — указатель на целое, куда записывается реальная длина описания источника данных.
2. Функция SQLConfigDataSources добавляет, изменяет или удаляет указанный источник данных.
BOOL SQLConfigDataSources(HWND hwndParent, WORD fRequest, LPCSTR lpszDriver, LPCSTR lpszAttributes)
- hwndParent — хэндл родительского окна. Если не равен NULL, отображается стандартный для данного типа источника данных диалог настройки.
- fRequest — тип запрашиваемой операции. Может принимать следующие значения:
- ODBC_ADD_DSN (ODBC_ADD_SYS_DSN) — запрос на создание нового пользовательского (системного) источника данных;
- ODBC_CONFIG_DSN (ODBC_CONFIG_SYS_DSN) — запрос на изменение существующего пользовательского (системного) источника данных;
- ODBC_REMOVE_DSN (ODBC_REMOVE_SYS_DSN) — удаление пользовательского (системного) источника данных.
Приведем несколько примеров строки атрибутов, чтобы вам было понятно, что это такое:
«DSN=MySource\0UID=MyLogin\0PWD=MyPass» — источник данных с именем MySource, логин — MyLogin, пароль — MyPass
Каждый драйвер «понимает» свои ключевые слова, чаще всего применяются:
PWD - пароль UID - логин DSN - имя источника данных DATABASE - имя базы данных SERVER - имя сервера, на котором находится база данных
Для баз данных Microsoft Access для указания имени БД вместо DATABASE используется ключевое слово DBQ.
3. Функция SQLAllocEnv создает новый хэндл для использования в других функциях и инициализирует интерфейс для работы с ODBC
RETCODE SQLAlocEnv(HENV * hEnv)
hEnv — указатель на переменную, которая будет хранить созданный хэндл в случае удачного выполнения функции
4. Функция SQLFreeEnv удаляет заданный хэндл и освобождает всю память, ассоциированную с ним.
RETCODE SQLFreeEnv(HENV hEnv)
- hEnv — хэндл, который нужно удалить
Исходный код
Сначала несколько замечаний. В C++Builder есть заголовочные файлы для работы с ODBC. Нам нужно два из них — odbcinst.h и sql.h. Добавьте строки
#include #include
в начало вашего файла. Реализация функций, описанных в этих файлах, находится в нескольких DLL, лежащих в каталоге Windows\System (или WinNT\System32). В наших примерах будут использоваться две такие DLL, а именно odbc32.dll и odbccp32.dll. Чтобы подключить их к проекту, нужно проделать следующие шаги:
1. Запускаем любой досовский файл-менеджер или командную строку Windows и переходим в каталог Windows\System (WinNT\System32) и находим эти две библиотеки.
2. Если каталог BIN С++Builder’а прописан в переменной окружения PATH, просто набираем
c:\windows\system\> implib odbc32.lib odbc32.dll
иначе набираем полностью путь к файлу implib.exe, либо копируем его в каталог, прописанный в PATH.
3. То же самое проделываем с odbccp32.dll:
c:\windows\system\> implib odbccp32.lib odbccp32.dll
4. Полученные .lib — файлы копируем в каталог с проектом
5. Из меню Project выбираем пункт Add to Project. и поочередно добавляем odbc32.lib и odbccp32.lib.
Все, теперь система сама загрузит эти DLL во время запуска программы.
Пример 1: Получаем список уже созданных источников данных ODBC.
const short SQL_MAX_DSN_LENGTH=255; UCHAR szDSN[ SQL_MAX_DSN_LENGTH+1 ]; UCHAR szDescription[ 256 ]; short wDSNLen; short wDesLen; int retCode; SQLHENV hEnv=NULL; AnsiString DSNName; SQLAllocEnv( &hEnv ); retCode = SQLDataSources( hEnv, SQL_FETCH_FIRST, szDSN, SQL_MAX_DSN_LENGTH+1, &wDSNLen, szDescription, 256, &wDesLen ); while( retCode == SQL_SUCCESS || retCode == SQL_SUCCESS_WITH_INFO ) < DSNName = (AnsiString)((char *)szDSN); // -- получили имя DSN в переменной DSNName retCode = SQLDataSources( hEnv, SQL_FETCH_NEXT, szDSN, SQL_MAX_DSN_LENGTH+1, &wDSNLen, szDescription, 256, &wDesLen ); >SQLFreeEnv( hEnv );Этот фрагмент кода просто перебирает все уже созданные источники данных. В первой строке фрагмента после объявления переменных создается хэндл текущего сеанса работы с ODBC, затем выбирается первое имя DSN. Если первое имя успешно прочитано (retCode содержит константу SQL_SUCCESS), то в цикле выбирается следующий DSN и т.д. до тех пор, пока не будет прочитан последний DSN. Если на место комментария вставить код (ListBox1 -> Items -> Add(DSNName)), добавляющий прочитанное имя в ListBox, например, то вы сможете просмотреть весь этот список. А если на место комментария вставить что-нибудь типа
if (DSNName=='OurDSN') .
то мы проверим, сможет ли наша программа работать нормально.
Пример 2: Создаем новый источник данных.
В этом примере вы узнаете, как создать системный DSN для базы данных Access. Предположим, файл с БД лежит в том же каталоге, что и программа, а его имя — db1.mdb.
#include WORD fRequest = ODBC_ADD_SYS_DSN; UCHAR lpszDriver[] = "Microsoft Access Driver (*.mdb)"; UCHAR lpszAttributes[255] = "DSN=c2a;DBQ="; bool retCode; AnsiString CurDir; CurDir = GetCurrentDir(); StrCat(lpszAttributes, CurDir.c_str()); StrCat(lpszAttributes, "\\db1.mdb"); retCode = SQLConfigDataSource(NULL, fRequest, lpszDriver, lpszAttributes); if (retCode == true) Application -> MessageBox("DSN успешно создан", "Сообщение", MB_OK); else < Application ->MessageBox("Произошла ошибка во время создания DSN", "Ошибка", MB_OK); >Как видите, здесь уже не нужны хэндлы и код достаточно ясный. В первых трех строках — дописываем в строку атрибутов путь к файлу БД. Затем собственно создаем источник. Обработка ошибок тривиальна.
Важное замечание: При создании DSN если такое имя уже есть, то не возвращается ошибка, а создается DSN с текущими параметрами.
Пример 3: Как все это собрать воедино и использовать в программе
Здесь кода не будет, здесь будет описание. Итак, у нас есть программа, которой нужно «присоединиться» к базе Microsoft Access, лежащей совсем рядом, в текущем каталоге. На машине пользователя нам не нужно ничего, кроме стандартного набора bpl и BDE. Но — теперь не нужны SQL Links, можно использовать, например, Install Shield, можно взять отдельный дистрибутив BDE. Поехали:
1. На основную форму проекта кидаем компоненту TDatabase. Устанавливаем ее свойства: LoginPrompt — false, DatabaseName — dbMain, AliasName — c2a (имя источника данных ODBC). Во всех компонентах TQuery или TTable свойство Database Name будет равно dbMain. Конечно, можно не использовать компоненту TDatabase, а в TQuery или TTable прямо указывать имя источника данных ODBC, но представьте, если вы написаи проект формочек на двадцать-тридцать, а потом решили, что имя источника ‘MySuperDSN’ не в полной мере отражает всю вашу крутость 🙂 Изменять свойство у полусотни компонент — очень муторное занятие, поверьте.
2. В конструкторе основной формы прописываем код примера №1, вставляя на место комментария следующий код:
if (t == «c2a»)
а после цикла — такой фрагмент:
if (!Exists)
3. Функция NewDSN() полностью повторяет код примера №2.
Теперь при первом запуске программы будет создан источник данных ODBC Microsoft Access с именем c2a, ссылающийся на файл db1.mdb, лежащий в том же каталоге, что и программа.
4. На всякий непредвиденный случай (если вы переместили программу в другой каталог, поменялась буква диска или сетевое имя, где лежит база данных) можно в программе предусмотреть немедленное перезаписывание DSN по горячей клавише, что-то типа такого:
void __fastcall TForm1::FormKeyDown(TObject *Sender, WORD &Key, TShiftState Shift) < if (Shift.Contains(ssAlt) && Shift.Contains(ssCtrl)) if (Key==VK_F1) < if (Application ->MessageBox("Перезаписать DSN?", "Вопрос",MB_YESNO)==IDYES) < NewDSN(); >> >Здесь для перезаписи DSN используется комбинация Alt-Ctrl-F1
Что такое ODBC?
Многие неправильные представления об ODBC существуют в вычислительном мире. Для конечного пользователя это значок в панель управления Microsoft Windows. Программист приложений — это библиотека, содержащая подпрограммы доступа к данным. Для многих других это ответ на все проблемы доступа к базе данных, которые когда-либо представляли.
В первую очередь ODBC — это спецификация API базы данных. Этот API не зависит от любой субД или операционной системы; Хотя в этом руководстве используется C, API ODBC не зависит от языка. API ODBC основан на спецификациях CLI из Open Group и ISO/IEC. ODBC 3.x полностью реализует обе эти спецификации — более ранние версии ODBC были основаны на предварительных версиях этих спецификаций, но не полностью реализовали их — и добавляет функции, часто необходимые разработчикам приложений баз данных на основе экрана, таких как прокручиваемые курсоры.
Функции в API ODBC реализуются разработчиками драйверов, относящихся к СУБД. Приложения вызывают функции в этих драйверах для доступа к данным независимо от СУБД. Диспетчер драйверов управляет взаимодействием между приложениями и драйверами.
Хотя корпорация Майкрософт предоставляет диспетчер драйверов для компьютеров под управлением Microsoft Windows 95 и более поздних версий, написала несколько драйверов ODBC и вызывает функции ODBC из некоторых своих приложений, любой пользователь может писать приложения и драйверы ODBC. На самом деле подавляющее большинство приложений и драйверов ODBC, доступных сегодня, написаны компаниями, отличными от Корпорации Майкрософт. Кроме того, драйверы и приложения ODBC существуют на macOS и различных платформах UNIX.
Чтобы помочь разработчикам приложений и драйверов, корпорация Майкрософт предлагает пакет SDK для программного обеспечения ODBC для компьютеров под управлением Windows 95 и более поздних версий, который предоставляет диспетчер драйверов, библиотеку DLL установщика, средства тестирования и примеры приложений. Корпорация Майкрософт объединилась с Visigenic Software, чтобы перенести эти пакеты SDK на Macintosh и различные платформы UNIX.
Важно понимать, что ODBC предназначен для предоставления возможностей базы данных, а не дополнения их. Таким образом, средства записи приложений не должны ожидать, что использование ODBC внезапно преобразует простую базу данных в полнофункциональный реляционный ядро СУБД. Не требуется, чтобы записи драйверов реализовали функциональные возможности, не найденные в базовой базе данных. Исключением из этого является то, что разработчикам, которые записывают драйверы, которые напрямую обращаются к данным файлов (например, данным в Xbase-файле), требуются для записи ядра СУБД, поддерживающего по крайней мере минимальные функциональные возможности SQL. Другим исключением является то, что компонент ODBC пакета SDK для Windows, ранее включенный в пакет SDK для компонентов доступа к данным (MDAC), предоставляет библиотеку курсоров, которая имитирует прокручиваемые курсоры для драйверов, реализующих определенный уровень функциональности.
Приложения, использующие ODBC, отвечают за любые функции между базами данных. Например, ODBC не является разнородным ядром соединения, а также не обработчиком распределенных транзакций. Тем не менее, так как она является независимой от СУБД, ее можно использовать для создания таких межбазовых средств.
Обратная связь
Были ли сведения на этой странице полезными?
Механизм работы СУБД — зачем нужен универсальный драйвер ODBC, если есть универсальный язык SQL?
Собственно вопрос, каков механизм выполнения запросов к СУБД (например, пусть это будет MySQL) и какова роль в этом механизме таких компонентов, как язык SQL и ODBC? Непонятно вот что, если есть универсальный язык выполнения запросов, который нивелирует различия между СУБД, зачем нужен ещё и универсальный драйвер?
Отслеживать
задан 18 янв 2017 в 12:14
1,294 16 16 серебряных знаков 38 38 бронзовых знаковsql (язык) — не универсален. Есть диалекты. odbc это один из стандартов (библиотек), позволяющий как сделать запрос, так и узнать список таблиц полей процедур не используя запросы. Кроме odbc есть ещё jdbc, oledb и другие.
18 янв 2017 в 12:19
@nick_n_a, наличие диалектов не отменяет его универсальности, в противном случае в нём бы не было необходимости. Большинство запросов, написанных в соответствии со стандартом, будут одинаково интерпретированы на большинстве реляционных СУБД. А если вы под диалектами понимаете нечто вроде T-SQL или PL/SQL, ну так это скорее процедурные расширения универсального SQL, о которых, замечу, в вопросе речи не шло.
18 янв 2017 в 13:27
Вам правильно ответили. sql = язык. odbc = библиотека (интерфейс для драйверов) к СУБД. odbc может выполнять sql, а sql выполнять odbc нет (sql не связан с odbc). Под универсальностью я имел ввиду то что sql(mysql):show tables не будет равен sql(mssql):select * from sys.tables , а в odbc предусмотрена функция типа gettables которая всегда одинаково вернёт список таблиц для любой СУБД.
18 янв 2017 в 13:31
2 ответа 2
Сортировка: Сброс на вариант по умолчанию
SQL это язык запросов. ODBC это способ подключения к конкретному серверу конкретной БД. Все БД имеют разные протоколы для доступа к серверу БД. ODBC предоставляет унифицированный интерфейс и скрывает конкретную реализацию протокола доступа.
Отслеживать
ответ дан 18 янв 2017 в 12:19
Mikhail Vaysman Mikhail Vaysman
14.3k 1 1 золотой знак 21 21 серебряный знак 31 31 бронзовый знакЗадача драйвера не только передать SQL-запрос серверу, такой протокол передачи можно было бы стандартизироать, если бы он был просто текстом. Но есть такая вещь как передаваемые в запрос параметры и самое главное — результат выполнения запроса. Задача драйвера упаковывать запрос, параметры и результаты в пакеты передаваемые по сети. И формат упаковки языком никак не оговаривается и каждая СУБД реализует его по своему. Тем более, что во многих СУБД существуют не только разные типы данных, но и сложные типы, например, как массивы PostgreSQL, которых в стандартах SQL вообще нет. И как передавать по сети эти типы данных опять же каждая БД решает самостоятельно.
Поэтому для работы с СУБД программы линкуются с библиотеками (драйверами) конкретных СУБД, которые умеют общаться с конкретной БД. Драйвер ODBC предназначен для того, что бы программа могла быть слинкована с единственной библиотекой и через нее получать доступ к разным БД, понятно, что при этом программа не сможет получить доступ к не стандартным типам данных и надо будет ограничиваться в работе стандартизированными, боле менее одинаковыми в разных СУБД возможностям языка SQL.
Отслеживать
ответ дан 18 янв 2017 в 12:23
44.1k 3 3 золотых знака 35 35 серебряных знаков 66 66 бронзовых знаков- sql
- база-данных
- драйвер
- odbc
-
Важное на Мете
Похожие
Подписаться на ленту
Лента вопроса
Для подписки на ленту скопируйте и вставьте эту ссылку в вашу программу для чтения RSS.
Дизайн сайта / логотип © 2024 Stack Exchange Inc; пользовательские материалы лицензированы в соответствии с CC BY-SA . rev 2024.3.8.5973
Программный интерфейс ODBC (Open Database Connectivity)
ODBC — это программный интерфейс (API) доступа к базам данных, разработанный компанией Microsoft.
C помощью ODBC программисты могут разрабатывать приложения для использования одного интерфейса доступа к данным, не беспокоясь о тонкостях взаимодействия с несколькими источниками.
Это достигается благодаря тому, что поставщики различных баз данных создают драйверы, реализующие конкретное наполнение стандартных функций из ODBC API с учётом особенностей их продукта. Приложения используют эти функции, реализованные в соответствующем конкретному источнику данных драйвере, для унифицированного доступа к различным источникам данных.
Определяют два типа драйверов — одноуровневые и многоуровневые. Одноуровневые обрабатывают вызовы ODBC и операторы SQL. Многоуровневые обрабатывают только вызовы ODBC, оставляя СУБД осуществлять обработку SQL-запросов.
Драйверы ODBC могут поддерживать многопоточность (multithreaded driver), то есть с одним драйвером могут одновременно работать несколько приложений в синхронном режиме. В случае, если драйвер не является многопоточным, он работает только в асинхронном режиме.
Источниками данных, например, могут быть: реляционная база данных, хранилище данных, база данных индексно-последовательного метода доступа (ISAM), электронная таблица Microsoft Excel или текстовый файл. Кроме того, через ODBC можно подключиться и к таким источникам данных, как: Hive, MongoDB, Cassandra, Impala, CouchDB, HBase и прочие.
В Loginom существует встроенная интеграция, которая дает возможность настроить подключение к ODBC источнику данных.