Какая функция odbc распределяет память для заданного идентификатора окружения
Как замечено выше, программный SQL отличается от обычной, интерактивной формы наличием некоторых специальных инструкций, а также механизмом трансляции и выполнения запросов. Таким образом, для применения программного SQL в тексте своих программ программистам необходимо ознакомиться с некоторым специфическим набором инструкций. Стоит заметить, что в разных СУБД эти наборы инструкций, вообще говоря, могут несколько отличаться друг от друга. В результате возникает некоторая проблема, связанная с непереносимостью программы.
Наряду с описанным выше механизмом существует и активно применяется еще один подход, связанный с наличием специальных интерфейсов – API (application programming interface – интерфейс программирования приложений ). Эти API представляют собой библиотеки функций, разработанные для обеспечения связи прикладной программы с СУБД посредством выполнения SQL-запросов. Прикладная программа вызывает специальные функции библиотеки для передачи в СУБД SQL -запроса в текстовом виде и для получения результатов выполнения запросов, а также различной служебной информации.
Применение подобного подхода приводит к тому, что программистам более не требуется изучать специальные наборы инструкций SQL , а необходимо лишь изучить специальную библиотеку функций. С учетом того, что механизм использования API является широко используемым и стандартным подходом (чего только стоит использование мощного аппарата Windows API ), для специалистов нет ничего нового в изучении еще одной библиотеки, в данном случае – для общения с СУБД .
Кроме этого, программа , содержащая вызовы некоторых функций специализированной библиотеки, ничем не отличается по схеме компиляции и выполнения от обычной программы. Так, подобная программа не требует применения специализированного препроцессора с механизмом раздельной компиляции. Может показаться, что подход, связанный с использованием библиотек API , является наиболее прогрессивным, на самом же деле такой вывод вряд ли верен. Так, на настоящий момент очень активно используются и динамический SQL и библиотеки API . В каждом из этих подходов существуют свои достоинства, недостатки и границы разумной применимости. Как обычно, выбор того, каким из подходов воспользоваться, лежит на административной группе разработчиков базы данных , которая принимает решения в зависимости от особенностей конкретной задачи и имеющихся специалистов.
В данном разделе рассматривается подход, основанный на интерфейсе программирования приложений .
Посмотрим, как работают прикладные программы, использующие различные API . Принципы работы разных библиотек аналогичны. Схема работы приложения совместно с SQL API выглядит следующим образом [ [ 3.1 ] ]:
- программа получает доступ к базе данных путем вызова одной или нескольких API-функций, подключающих программу к СУБД и к конкретной базе данных;
- для пересылки инструкций SQL в СУБД программа формирует инструкцию в виде текстовой строки и затем передает эту строку в качестве параметра при вызове API-функции;
- программа вызывает выполнение API-функции для проверки состояния переданной в СУБД инструкции и обработки ошибок;
- если инструкция SQL представляет собой запрос на выборку, то, вызывая API-функции, программа записывает результаты запроса в свои переменные; обычно за один вызов возвращается одна строка или столбец данных;
- свое обращение к базе данных программа заканчивает вызовом API-функции, отключающей ее от СУБД.
Из имеющихся для реализации SQL -запросов интерфейсов API на настоящий момент выделилось несколько библиотек, "стандартных" в том смысле, что они активно применяются множеством разработчиков по всему миру. Данное пособие не является подробным руководством по всем этим библиотекам. Более того, для их профессионального освоения необходимо серьезное изучение соответствующей литературы. В рамках данного курса мы лишь приведем обзор этих библиотек, рассмотрим основные заложенные в них идеи. Подробно эти SQL API описаны, например в [ [ 3.1 ] ].
Протокол ODBC
ODBC (Open Database Connectivity – открытый доступ к базам данных) – разработанный компанией Microsoft универсальный интерфейс программирования приложений для доступа к базам данных [ [ 3.1 ] ].
Основной целью разработки протокола ODBC считается стандартизация механизмов взаимодействия с различными СУБД. Основная проблема, связанная с разработкой приложений, взаимодействующих с базами данных на основе специальных SQL API, состояла в том, что каждая СУБД имела собственный программный интерфейс доступа, каждый из них имел свои особенности и функционировал не совсем так, как другие. В связи с этим разработка приложения существенно зависела от используемой СУБД. Компания Microsoft сделала важный шаг для решения этой проблемы. Основная идея заключалась в разработке универсального интерфейса на уровне семейства операционных систем Windows, который мог бы быть поддержан в разных СУБД.
Рассмотрим кратко структуру программного обеспечения ODBC [ [ 3.1 ] ]:
- интерфейс вызовов функций ODBC: это так называемый верхний уровень ODBC, содержащий API , который и используется непосредственно приложениями. Данный API реализован в виде библиотеки динамической компоновки Dll и входит в состав операционной системы Windows;
- драйверы ODBC: это так называемый нижний уровень ODBC, содержащий набор драйверов для СУБД, поддерживающих протокол ODBC. В рамках технологии для каждой СУБД может быть разработан соответствующий ODBC-драйвер, который будет являться промежуточным звеном между прикладной программой и СУБД, транслируя вызовы функций СУБД в вызовы внутренних специализированных функций СУБД . Таким образом решается проблема стандартизации. Для многих современных СУБД существуют специализированные драйверы ODBC , отдельно устанавливаемые в операционную систему;
- диспетчер драйверов ODBC: данный программный механизм представляет средний уровень ODBC, управляя процессом загрузки необходимых драйверов.
Схема выполнения программы с использованием протокола ODBC для доступа к данным приводится на рис. 13.5.
Перечень некоторых базисных функций ODBC API приводится в следующей таблице.
Протокол JDBC
JDBC (Java Database Connectivity) представляет собой API для выполнения SQL-запросов к базам данных из программ, написанных на языке Java [ [ 3.1 ] ].
Рассмотрим основные принципы JDBC.
С развитием глобальных сетей, в частности Интернета, и всех сопутствующих технологий стали появляться новые языки, специально предназначенные для работы в новых условиях. Одним из таких языков является язык программирования Java . В настоящее время Интернет-приложения занимают существенное место на рынке, работая в рамках 2-, 3- и многозвенной архитектуры . При этом значение языка Java как средства создания приложений, работающих с базами данных, существенно возрастает. Именно это и явилось одной из основных причин разработки нового программного интерфейса – JDBC. Первоначально интерфейс JDBC был разработан компанией Sun Microsystems, в настоящий момент этот API поддерживается всеми ведущими коммерческими СУБД.
Известно несколько различных версий JDBC. Так, версия 1.0 содержала некоторые средства доступа к данным:
- диспетчер драйверов (для подключения к разным СУБД);
- механизм управления сеансами (для одновременной работы с несколькими СУБД);
- механизм передачи инструкций SQL на выполнение в СУБД;
- механизм работы с курсорами (для передачи результатов выполнения запросов из СУБД в приложение).
Этот перечень определенным образом напоминает аналогичный функциональный аппарат протокола ODBC.
Версия JDBC 2.0 содержит существенные отличия. Так, вследствие увеличения возможностей интерфейса было проведено его идеологическое разделение на две основные части: Core API (основные возможности) и Extensions API (так называемые расширения).
В [ [ 3.1 ] ] указаны следующие возможности JDBC:
- Пакетные операции. Программа на Java может осуществить обновление базы данных в пакетном режиме, т.е. одна функция JDBC может добавить в базу данных несколько записей, что положительно сказывается на производительности программ.
- Курсоры с произвольным доступом. В JDBC 2.0 существует средство, позволяющее перемещаться по результатам запроса произвольным образом.
- Обновляемые курсоры. В JDBC 2.0 курсоры, наряду с функцией возврата результата запроса, используются и при обновлении базы данных. Обновления производятся при добавлении или изменении одной из строк в результатах запроса.
- Организация связного пула. Несколько программ на языке Java могут пользоваться совместным доступом к базе данных, уменьшая затраты на подключения к базе данных и отключения от нее. Данный перечень можно продолжить (распределенные транзакции, поддержка JNDI и т.д.).
Версия JDBC 3.0 появилась совсем недавно и содержит такие новации, как объектно-реляционные расширения SQL и улучшенные механизмы обработки транзакций. Архитектура JDBC берет свое начало от ODBC и в существенной части повторяет ее, поэтому схема выполнения программы на Java с использованием протокола JDBC для доступа к данным полностью аналогична схеме на рис. 13.5 (слова ODBC заменяются на слова JDBC). В отличие от ODBC, драйверы JDBC подразделяются на четыре типа. Основные отличия между этими типами связаны с местонахождением API СУБД (на клиентской или серверной СУБД) и способом доступа к базе данных (через собственный API СУБД или через ODBC).
Библиотека DB-Library
Библиотека DB-Library реализует интерфейс программирования приложений для совместной работы с широко распространенной СУБД Microsoft SQL Server. Данная библиотека является весьма обширной и содержит более 100 функций. Основными из них являются:
- dblogin(); dbopen() – подключение к БД;
- dbopen(); dbexit() – установка/разрыв соединения с БД;
- dbcmd() – передача инструкции (пакета инструкций) SQL в СУБД в текстовом виде;
- dbSQLexec() – требование к СУБД выполнить текущий пакет инструкций;
- dbcancel() – прекращение выполнения пакета инструкций SQL;
- dbresults() – получение результатов выполнения очередной инструкции SQL в текущем пакете;
- dbbind(), dbdata(), dbnextrow(), dbnumcols(), dbdatlen() и др. – обработка результатов запросов на выборку данных.
Логика работы прикладной программы, обрабатывающей данные, хранящиеся в базе данных под управлением Microsoft SQL Server, выглядит следующим образом:
- при помощи указанных выше функций ( dblogin(), dbopen() ) прикладная программа формирует сведение об авторизации и пытается установить соединение с СУБД;
- при помощи СУБД программа открывает конкретную базу данных, с которой будет происходить работа ( dbopen() );
- при помощи специальной функции ( dbcmd() ) программа передает в СУБД текст SQL-инструкции, которую далее необходимо будет выполнить; в библиотеке DB-Library поддерживается так называемый пакетный режим работы. Данный режим подразумевает возможность создания пакетов инструкций. Так, вызывая функцию dbcmd() несколько раз, вы можете передать в СУБД текст нескольких команд SQL, которые впоследствии будут выполнены как одна команда;
- используя функцию dbSQLexec() , программа вызывает выполнение инструкций, переданных ранее при помощи вызовов функций dbcmd() ;
- вызывая функцию dbresults() , программа может определить, удалось ли СУБД выполнить очередную инструкцию (как правило, число вызовов dbresults() соответствует числу инструкций в очередном пакете);
- в случае если мы имеем дело с запросом, возвращающим набор строк в качестве результата (запросом на выборку), программа при помощи вызовов функции dbbind() осуществляет связывание каждого поля результатов запроса с некоторой областью оперативной памяти. Далее при помощи функции dbnextrow() программа выполняет переход к следующей строке результатов запроса, что приводит к помещению в буфер новых данных;
- при помощи функции dbexit() программа разрывает соединение с базой данных. Библиотека DB-Library представляет собой большой и сложный механизм. Так, в библиотеке предусмотрены специальные механизмы обработки ошибок, разные способы передачи результатов выполнения запросов в прикладную программу и т.д.
Краткие итоги: В лекции рассматриваются разные технологии формирования запросов на языке SQL в прикладных программах (программный SQL ). Дается понятие статического SQL , динамического SQL и приводятся соответствующие основные операторы . Рассматриваются интерфейсы программирования приложений ( API ) (протокол ODBC , протокол JDBC , библиотека DB-Library).
Сводка
Функцию SQLAllocHandle выделяет среду, соединение, инструкцию или дескриптор.
Эта функция является универсальной функцией выделения дескрипторов, которые заменяют функции ODBC 2,0 SQLAllocConnect, SQLAllocEnv и SQLAllocStmt. Чтобы разрешить приложениям, вызывающим функцию SQLAllocHandle , работать с ODBC 2. драйверы x , вызов функцию SQLAllocHandle сопоставляется в диспетчере драйверов с SQLAllocConnect, SQLAllocEnv или SQLAllocStmt, в зависимости от ситуации. Дополнительные сведения см. в разделе "Комментарии". Дополнительные сведения о том, что диспетчер драйверов сопоставляет эту функцию при использовании ODBC 3. Приложение x работает с ODBC 2. драйвер x см. в разделе Сопоставление функций замены для обратной совместимости приложений.
Аргументы
SQL_HANDLE_DBC_INFO_TOKENный обработчик используется только диспетчером драйверов и драйвером. Приложения не должны использовать этот тип обработчика. Дополнительные сведения о SQL_HANDLE_DBC_INFO_TOKEN см. в разделе Разработка осведомленности Connection-Pool в драйвере ODBC.
аутпусандлептр
Проверки Указатель на буфер, в который будет возвращен маркер для вновь выделенной структуры данных.
Выделение дескриптора дескриптора
Когда приложение вызывает функцию SQLAllocHandle с параметром handletype SQL_HANDLE_DESC, драйвер выделяет дескриптор приложения. Они называются явно выделенными дескрипторами. Приложение направляет драйвер для использования явно выделенного дескриптора приложения вместо автоматического выделения единицы для данного дескриптора инструкции путем вызова функции SQLSetStmtAttr с атрибутом SQL_ATTR_APP_ROW_DESC или SQL_ATTR_APP_PARAM_DESC. Дескриптор реализации не может быть выделен явным образом, а в вызове функции SQLSetStmtAttr нельзя указывать дескриптор реализации.
Явно выделенные дескрипторы связаны с дескриптором соединения вместо дескриптора оператора (так как автоматически назначаемые дескрипторы). Дескрипторы остаются выделены только тогда, когда приложение фактически подключается к базе данных. Так как явно выделенные дескрипторы связаны с дескриптором соединения, приложение может связать явно выделенный дескриптор с более чем одной инструкцией в пределах соединения. Неявно выделенный дескриптор приложения, с другой стороны, не может быть связан с более чем одним дескриптором инструкции. (Он не может быть связан с каким-либо другим маркером инструкции, который был выделен для.) Явно выделенные дескрипторы дескриптора можно освободить явным образом либо с помощью приложения, либо путем вызова SQLFreeHandle с параметром handletype SQL_HANDLE_DESC или неявно при закрытии соединения.
При освобождении явно выделенного дескриптора, неявно выделенный дескриптор снова связывается с инструкцией. (Атрибут SQL_ATTR_APP_ROW_DESC или SQL_ATTR_APP_PARAM_DESC для этой инструкции снова задается неявно выделенным дескриптором дескриптора.) Это справедливо для всех инструкций, которые были связаны с явно выделенным дескриптором в соединении.
Дескриптор - это коллекция метаданных, которые описывают параметры инструкций SQL или столбцов с набором результатов, которые обрабатываются приложением или драйвером.
  Возможные возвращаемые значения SQLAllocHandle могут быть:
 
SQL_SUCCESS | Функция завершена успешно |
SQL_SUCCESS_WITH_INFO | Функция завершена успешно, но с предупреждением |
SQL_ERROR | Функция потерпела неудачу. |
SQL_INVALID_HANDLE | Идентификатор переданный функции, недействителен |
  Выполнилась ли функция успешно или потерпела неудачу, вы можете получить подробную информацию относительно этого, вызывая SQLGetDiagRec или SQLGetDiagField . Они играют ту же самую роль, что и GetLastError в Win32 API.
ВЫБОР ВЕРСИИ ODBC
  После выделения памяти для идентификатора окружения вы должны установить атрибут окружения, SQL_ATTR_ODBC_VERSION , в соответствующее значение. Установка значения атрибута окружения делается, вызовом SQLSetEnvAttr . К настоящему времени вы должны знать, что имеются также функции SQLSetConnectAttr и SQLSetStmtAttr . SQLSetEnvAttr определена как:
- EnvironmentHandle. Содержит идентификатор окружения, атрибут которого вы хотите установить.
- Attribute. Константа, которая представляет атрибут, который выхотите установить. Для нашей цели, это - SQL_ATTR_ODBC_VERSION . Вы можете искать полный списокв MSDN.
- ValuePtr. Значение этого параметра зависит от атрибута, который вы хотите установить. Если атрибут - 32-разрядное значение, этот параметр обрабатывается как значение, которое вы хотите установить. Если атрибут - текстовая строка или двоичный буфер, то это интерпретируется как указатель на строку или буфер. Если вы определяете SQL_ATTR_ODBC_VERSION , то имеются два возможных значения, которые вы можете использовать: SQL_OV_ODBC3 и SQL_OV_ODBC2 , для ODBC версий 3.x и 2.x соответственно.
- StringLength. Размер значения, указанного ValuePtr . Если значение - строка или двоичный буфер, этот параметр должен быть действителен. Если атрибут, который вы хотите установить - dword, этот параметр игнорируется. С тех пор как SQL_ATTR_ODBC_VERSION атрибут содержит значение dword, вы можете передавать NULL как этот параметр.
  Список возможных возвращаемых значений идентичен SQLAllocHandle.
ВЫДЕЛЕНИЕ ПАМЯТИ ДЛЯ ИДЕНТИФИКАТОРА ПОДКЛЮЧЕНИЯ
  Этот шаг подобен выделению памяти для ид. окружения, вы также вызываете SQLAllocHandle , но передаёте другое значение параметра.
УСТАНОВКА СВЯЗИ
  Теперь мы готовы сделать попытку фактического подключения к источнику данных через выбранный ODBC драйвер. Имеются фактически три функции ODBC, которые мы можем использовать, чтобы достичь этой цели. Они предлагают различную степень "выбора", который вы можете сделать.
 
SQLConnect | Ядро | Это - самая простая функция. Требуется только DSN (название источника Данных) и необязательное название пользователя и пароль. Она не предлагает интерфейса GUI типа подсказки пользователю в виде диалого окна для получения дополнительной информации. Вы должны использовать эту функцию, если вы уже имеете DSN для заданной базы данных. |
SQLDriverConnect | Ядро | Эта функция предлагает более широкий спектр услуг чем SQLConnect. Вы можете соединяться с источником данных, который не определен в системной информации, то есть без DNS. Кроме того, вы можете определить, отобразит ли эта функция диалоговое окно, запрашивающее пользователя для получения дополнительной информации. Например, если вы опустили имя файла базы данных, она будет инструктировать ODBC драйвер об отображении диалогового окна, запрашивающего пользователя выбрать базу данных, для соединения с ней. |
SQLBrowseConnect | Уровень 1 | Эта функция предлагает перечисление источников данных во время выполнения. Она обеспечивает более гибкий интерфейс в сравнении с SQLDriverConnect, потому что вы можете вызывать SQLBrowseConnect неско раз последовательно, каждый раз запрашивая пользователя для получения более конкретной информации, пока наконец вы не получите рабочую строку подключения. |
  Я буду исследовать сначала SQLConnect. Чтобы использовать SQLConnect, вы должны знать кое-что относительно DSN. DSN расшифровывается как Название Источника Данных, т.е. это строка, которая уникально идентифицирует источник данных. DSN идентифицирует строение данных, которое содержит информацию о том, как соединиться с удельным источником данных. Информация включает и то, какой ODBC-драйвер использовать и с какой базой данных соединиться. Вы создаете, изменяете и удаляете DSN, используя 32-разрядного ODBC Администратора в панели управления.
  SQLConnect имеет следующий синтаксис:
- ConnectionHandle. Идентификатор подключения который вы хотите использовать.
- pDSN. Указатель на DSN-строку.
- DSNLength. Длина DSN-строки.
- pUserName. Указатель на строку содержащую имя пользователя.
- NameLength. Длинна строки содержащей имя пользователя.
- pPassword. Указатель на строку содержащую пароль ассоциированный с данным именем пользователя.
- PasswordLength. Длина пароля
  По минимуму, SQLConnect требует идентификатор соединения, DSN и их длинну: имя пользователя и пароль необязательны, если источник данных не требует их. Список возможных возвращаемых значений идентичен таковому SQLAllocHandle. Предположим мы имеем DSN называемый "Продажи" в нашей системе, и мы хотим соединиться с ним. Мы можем сделать это следующим образом:
  Один из недостатоков SQLConnect - то, что, вы должны создать DSN прежде, чем сможете соединяться с источником данных. SQLDriverConnect предлагает более гибкий вариант. Она имеет следующий синтаксис:
- ConnectionHandle. Идентификатор соединения.
- hWnd. Дескриптор вашего окна. Если вы передадите NULL как параметр, драйвер не будет запрашивать пользователя для получения дополнительной информации (если необходимо).
- pInConnectString.Указатель на строку подключения. Это - ASCIIZ строка, которая отформатирована, согласно специфике ODBC драйвера, с которым вы хотите соединиться. Она описывает название драйвера и источника данных а так же некоторые дополнительные параметры. Полное описание строки подключения можно найти в MSDN. Здесь я не буду углублятся в подробности.
- InStringLength. Длина строки соединения.
- pOutConnectString. Указатель на буфер, который будет заполнен законченной строкой подключения. Размер этого буфера должен быть по крайней мере 1,024 байта. Это может звучать запутывающе. Если строка подключения, которую вы передаёте функции, не закончена, то в этом случае, ODBC драйвер может запрашивать пользователя для получения дополнительной информации. ODBC драйвер в этом случае создает законченную строку подключения из всей располагаемой информации и помещает её в буфер. Даже если строка подключения, которую вы составили, была функциональна, этот буфер будет заполнен большим количеством атрибутов. Цель этого параметра - сохранить законченную строку подключения для будущего подключения.
- OutBufferSize. Размер буфера, указанного pOutConnectString.
- pOutConnectStringLength. Указатель на dword переменную, которая получит фактическую длину законченной строки подключения, возвращенной ODBC драйвером.
- DriverCompletion. Флаг, который определяет запросит ли ODBC менеджер/драйвер пользователя для получения дополнительной информации. Однако, флаг зависит от того, передаёте ли вы дескриптор окна hWnd параметру SQLDriverConnect. Если вы не делали этого, ODBC менеджер/драйвер не будет запрашивать пользователя, даже если этот флаг инструктирует об этом.
SQL_DRIVER_PROMPT ODBC драйвер запрашивает пользователя относительно информации. Эта информация используется для создания строки подключения. SQL_DRIVER_COMPLETE
SQL_DRIVER_COMPLETE_REQUIREDODBC драйвер запросит пользователя только, если строка подключения, составленная в вашей программе не закончена. SQL_DRIVER_NOPROMPT ODBC драйвер не будет запрашивать пользователя для получения дополнительной информации.
РАЗЪЕДИНЕНИЕ С ИСТОЧНИКОМ ДАННЫХ
  После того, как подключение сделано успешно, вы можете создать одну или большее количество инструкций и сделать запрос источнику данных. Я буду исследовать эту часть на следующей консультации. Пока, давайте предположим, что вы уже отработали с источником данных, и должны разъединится с ним, вызывая SQLDisconnect. Эта функция проста (Это отражение грубой и грустной действительности о том, что разрушение - намного проще чем конструкция или созидание). Требуется только один параметр, маркер подключения.
УДАЛЕНИЕ ИДЕНТИФИКАТОРОВ ПОДКЛЮЧЕНИЯ И СРЕДЫ
  После успешного разъединения вы можете уничтожить идентификаторы подключения и среды, вызывая SQLFreeHandle. Это - новая функция, вводимая в ODBC 3.x., она заменяет SQLFreeConnect, SQLFreeEnvи SQLFreeStmt. SQLFreeHandle имеет следующий синтаксис:
Эта глава содержит общую информацию относительно ODBC и MyODBC.
Open Database Connectivity (ODBC) представляет собой интерфейс прикладной программы (API) для доступа к базам данных. Это основано на спецификациях Call-Level Interface (CLI) от X/Open и ISO/IEC для API баз данных. Как язык доступа к базам данных применяется Structured Query Language (SQL).
Первое и главное: ODBC является спецификацией для API базы данных. Этот API независим от любой СУБД, операционной системы или языка программирования.
ODBC API основан на спецификациях CLI от X/Open и ISO/IEC. ODBC 3.x полностью соответствует обоим этим спецификациям, более ранние версии ODBC были основаны на предварительных версиях этих спецификаций, но полностью не выполняли их, зато добавили свойства, нужные только разработчикам оконных приложений, например, прокручиваемые курсоры.
Разработчики драйверов для СУБД выполняют функции ODBC API. Приложения вызывают функции в этих драйверах, чтобы обратиться к данным способом, независимым от базы данных. Администратор драйверов (Driver Manager) управляет связью между прикладными программами и драйверами.
Имеются два архитектурных требования:
- Прикладные программы должны быть способны обратиться ко многим СУБД, используя тот же самый исходный текст без того, чтобы его перетранслировать или заново компоновать.
- Прикладные программы должны быть способны обратиться ко многим СУБД одновременно (через разные драйверы).
ODBC успешно решает эти проблемы следующим способом:
ODBC является интерфейсом уровня вызовов: Чтобы решить проблему с тем, как прикладные программы обращаются ко многим СУБД, используя один и тот же исходный текст, существует стандарт CLI. ODBC содержит все функции в спецификации CLI и обеспечивает дополнительные функции, обычно требуемые прикладными программами.
ODBC определяет стандартный синтаксис SQL: В дополнение к стандартному интерфейсу уровня обращения (вызова), ODBC определяет стандартный синтаксис SQL. Он базируется на спецификации X/Open SQL CAE. Если используемый ODBC синтаксис отличается от того, который применяет конкретная СУБД, производится преобразование на лету. Однако, такие преобразования редки потому, что большинство СУБД уже используют стандартный синтаксис языка SQL.
ODBC предоставляет Driver Manager для управления одновременным доступом к многим СУБД: Хотя использование драйверов решает проблему одновременного доступа ко многим базам данных, код, необходимый, чтобы сделать это, может быть сложен. Прикладные программы которые разработаны, чтобы работать со всеми драйверами, не могут быть статически связаны с любыми драйверами. Вместо этого они должны загрузить драйверы во время выполнения и вызывать функции в них через таблицу указателей функций. Ситуация становится более сложной, если прикладная программа использует много драйверов сразу. Чтобы избавить программу от проблем с этим, ODBC обеспечивает Driver Manager. Администратор драйверов (Driver Manager) осуществляет все функции ODBC обычно как вызовы функций ODBC в драйверах и статически связан с прикладной программой или загружен прикладной программой во время выполнения. Таким образом, вызовы из прикладной программы функций ODBC по именам обрабатываются в Driver Manager вместо того, чтобы обращаться по указателю к каждому драйверу. ODBC предоставляет много возможностей СУБД, но не требует, чтобы каждый драйвер поддерживал их все.
Архитектура MyODBC имеет 5 главных компонентов как показано ниже:
- Выбор сервера (MySQL) и связь с ним.
- Передача на рассмотрение инструкции SQL для выполнения.
- Получение результатов (если они есть).
- Обработка ошибок.
- Обработка транзакции или обратная перемотка.
- Отсоединение от сервера.
- Обработку Data Source Names (DSN).
- Загрузку и выгрузку драйверов.
- Обрабатку ODBC-обращения к функции или передачу вызова драйверу.
Как описано ранее, MySQL AB поддерживает два драйвера ODBC с открытыми исходными текстами, а именно MyODBC и MySQL ODBC 3.51, для работы с MySQL через ODBC API.
2.7.2.1 Требования
2.7.2.2 Построение MyODBC 3.51
MyODBC 3.51 поставляется в виде исходников с Makefile , который использует nmake . В дистрибутиве есть WIN_Makefile для формирования нормальной версии и WIN_Makefile_debug для формирования отладочной версии драйвера и DLL-библиотек. Для построения драйвера:
Скачайте исходники и распакуйте их в какой-нибудь каталог, скажем, myodbc3-src . Дальше выполните следующие команды для создания нормальной версии:
nmake -f Win_Makefile формирует версию драйвера и помещает двоичные файлы в подкаталог release . Команда nmake -f Win_Makefile install инсталлирует (вообще-то просто копирует) библиотеку драйвера и его DLL ( myodbc3.lib и myodbc3.dll ) в системный каталог ОС. Аналогично Вы можете сформировать версию для отладки, используя Win_Makefile_Debug :
Вы можете oчищать и восстанавливать драйвер, используя команды:
ОБРАТИТЕ ВНИМАНИЕ: Удостоверитесь, что определили правильные библиотеки пользователей MySQL и путь файлов заголовка в Makefile. Это принимает заданный по умолчанию путь C:\mysql\include и C:\mysql\lib\opt (для обычных DLL) или C:\mysql\lib\debug для отладочной версии.
Тестирование библиотек драйвера: после того, как библиотеки драйвера скопированы в системный каталог, Вы можете проверить качество их построения используя выборки, обеспеченные в подкаталоге samples каталога исходного текста:
2.7.2.3 Построение MyODBC 2.50
MyODBC распространяется в исходниках как VC Project для Windows. Можно формировать драйвер, используя прямые файлы проекта VC (.dsp и .dsw), имеющиеся в дистрибутиве.
Чтобы формировать драйвер самостоятельно под Linux, Вы должны иметь:
2.7.3.1 Требования
Как только Вы поимеете все требуемые файлы и распакуете исходные файлы в отдельный каталог, начинайте сборку драйвера как показано ниже.
2.7.3.2 Настройка
Единственные требуемые параметры; --with-mysql-libs=DIR и --with-mysql-includes=DIR . Здесь DIR задает каталог, где искать библиотеки и включаемые файлы mysql.
При использовании iodbc , если iodbc не установлен в заданное по умолчанию расположение ( /usr/local ), Вам придется использовать --with-iodbc=DIR или, если заголовки iODBC не находятся в DIR/include , придется использовать опцию --with-iodbc-includes=INCDIR . То же самое касается и библиотек: если они не в DIR/lib , примените явное указание параметром --with-iodbc-libs=LIBDIR .
При использовании unixODBC для создания configure ищите unixODBC вместо iODBC и используйте параметр --with-unixODBC=DIR . Здесь DIR задает то место, где установлен unixODBC.
Если звголовки и библиотеки unixODBC расположены не там, где надо (а надо в DIR/include и DIR/lib соответственно), укажите на них параметрами --with-unixODBC-libs=LIBDIR и --with-unixODBC-includes=INCDIR .
Вы можете определять другой префикс вместо /usr/local для установки, например, хранить MyODBC-драйверы в /usr/local/odbc/lib , для этого надо указать параметр --prefix=/usr/local/odbc .
Окончательно пример настройки выглядит так:
2.7.3.3 Построение библиотек драйвера
Для построения библиотек драйвера Вы должны только выполнить:
2.7.3.4 Установка библиотек драйвера
- libmyodbc3.so, libmyodbc3-3.51.01.so, здесь 3.51.01 является версией драйвера и libmyodbc3.a для MyODBC 3.51 или
- libmyodbc.so, libmyodbc-2.50.39.so, здесь 2.50.39 является версией драйвера и libmyodbc.a для MyODBC 2.50
Обратите внимание , если Вы пробуете использовать make из SUN , Вы закончите с ошибками. С другой стороны, Make от GNU должен работать прекрасно на всех платформах.
2.7.3.5 Замечания для Mac OS X
Если Вы хотите формировать драйвер на Mac OS (Darwin), то используйте следующий пример выбора конфигурации:
Это предполагает, что unixodbc и mysql установлены в заданные по умолчанию расположения. Если это не так, сконфигурируйте все соответственно.
2.7.3.6 Создание файлов .so
На большинстве платформ MySQL не формирует или поддерживает .so файлы, так как формирование с общедоступными библиотеками вызывало проблемы в прошлом.
В таких случаях пользователь должен скачать дистрибутив MySQL и скомпилировать его с помощью:
Если Вы все же хотите формировать общедоступные библиотеки драйвера, Вы должны определить опцию настройки --enable-shared .
Если Вы конфигурировали пакет с опцией --disable-shared , то Вы можете формировать .so-файл, используя следующее:
Предостережение: Вы должны читать этот раздел только, если Вы заинтересованы в разработке пакета. Если Вы только хотите получить MyODBC 3.51 , Вы должны использовать стандартный дистрибутив (исходный текст или двоичные модули).
Драйвер MySQL ODBC может использоваться на всех основных платформах, поддерживаемых MySQL:
- Все версии Windows: 95/98/NT/ME/2000/XP
- OS/2
- Mac OS X Server
- Amiga
- Все версии Unix:
- AIX
- BSDI
- DEC
- FreeBSD
- HP-UX
- Linux
- NetBSD
- OpenBSD
- SGI Irix
- Solaris
- SunOS
- SCO OpenServer
- SCO UnixWare
- Tru64 Unix
- Ошибки исправлялись быстро.
- Решать любые проблемы с MyODBC или MySQL.
- Была возможность заказывать свойство в драйвере.
- Иметь расширение драйвера.
- Иметь патчи, поставленные непосредственно в Ваш почтовый ящик.
- Иметь прямое взаимодействие с разработчиками MySQL и MyODBC.
Если Вы сталкиваетесь с трудностями с MyODBC или с MyODBC 3.51 , Вы должны запустить создание файла протокола из ODBC Manager (протокол Вы получаете при запросе файлов регистрации из ODBC ADMIN ) или протокол MyODBC (или MyODBC 3.51 ).
Для получения трассировки ODBC через Driver Manager, Вы должны сделать следующее:
Большинство программ должно работать с MyODBC , но для каждой из перечисленных ниже это было проверено непосредственно.
Название работы Кол-во страниц Размер Краткое. 5 Истоки tcp/IP. 6 Архитектура клиент-сервер. 10 Что такое. 1 329.62kb. Техническое задание на выполнение работ по модернизации медицинской. 4 580.52kb. История создания школьного лесничества 1 262.87kb. Реферат Данные, база данных, экспорт, импорт, soap сервер, soap клиент. 1 51.97kb. В базы данных 1 291.69kb. Контрольная работа По предмету: " Государственное устройство и самоуправление". 1 141.68kb. Методы окислительного обессеривания в приложении к дизельному топливу. 1 57.74kb. Руководство по личной и планетарной трансформации Эта книга обращена. 19 2367.85kb. Дисперсное армирование бетонов 1 185.88kb. Лекция Многопользовательские бд. Распределенные бд. Архитектура клиент-сервер 1 174.54kb. Зависимость размещения сорных растений в пределах угодья от некоторых. 1 21.92kb. 11 августа родились стивен Возняк 1 38.25kb. Направления изучения представлений о справедливости 1 202.17kb. Комментарии
Функцию SQLAllocHandle используется для выделения дескрипторов для сред, соединений, инструкций и дескрипторов, как описано в следующих разделах. Общие сведения об дескрипторах см. в разделе Handles.
Если драйвер поддерживает несколько выделений, то в каждый момент времени может быть выделено более одной среды, соединения или маркера инструкций. В ODBC ограничение на количество дескрипторов среды, соединения, инструкций или дескрипторов, которые могут быть выделены одновременно, не определено. Драйверы могут накладывать ограничение на количество определенных типов маркеров, которые могут быть выделены одновременно. Дополнительные сведения см. в документации по драйверу.
Если приложение вызывает функцию SQLAllocHandle с * аутпусандлептр , для которого задана среда, соединение, инструкция или дескриптор дескриптора, который уже существует, драйвер перезаписывает сведения, связанные с дескриптором, если только приложение не использует пул соединений (см. раздел "выделение атрибута среды для пулов соединений" Далее в этом разделе). Диспетчер драйверов не проверяет, используется ли уже указанный в * аутпусандлептр обработчик , а также не проверяет предыдущее содержимое маркера перед его перезаписыванием.
Неправильное программирование приложений ODBC для вызова функцию SQLAllocHandle в два раза с той же переменной приложения, определенной для * Аутпусандлептр , без вызова SQLFreeHandle для освобождения обработчика перед перераспределением. Перезапись дескрипторов ODBC таким образом может привести к несогласованному поведению или ошибкам в части драйверов ODBC.
В операционных системах, поддерживающих несколько потоков, приложения могут использовать одну среду, соединение, инструкцию или дескриптор в разных потоках. Поэтому драйверы должны поддерживать защищенный многопоточный доступ к этим сведениям. одним из способов достичь этого, например, является использование критического раздела или семафора. Дополнительные сведения о потоках см. в разделе Многопоточность.
Функцию SQLAllocHandle не устанавливает атрибут среды SQL_ATTR_ODBC_VERSION при вызове для выделения маркера среды; приложение должно быть установлено атрибутом среды, или значение SQLSTATE HY010 (ошибка последовательности функций) будет возвращаться при вызове функцию SQLAllocHandle для выделения маркера соединения.
Для приложений, соответствующих стандартам, функцию SQLAllocHandle сопоставляется с склаллочандлестд во время компиляции. Разница между этими двумя функциями заключается в том, что склаллочандлестд устанавливает атрибут среды SQL_ATTR_ODBC_VERSION SQL_OV_ODBC3 при вызове с аргументом параметром handletype , для которого задано значение SQL_HANDLE_ENV. Это делается потому, что приложения, соответствующие стандартам, всегда имеют формат ODBC 3. приложения x . Более того, для этих стандартов не требуется регистрация версии приложения. Это единственное различие между этими двумя функциями. в противном случае они идентичны. Склаллочандлестд сопоставляется с функцию SQLAllocHandle в диспетчере драйверов. Таким образом, сторонние драйверы не должны реализовывать склаллочандлестд.
Приложения ODBC 3,8 должны использовать:
Функцию SQLAllocHandle, а не склаллочандлестд , чтобы выделить маркер среды.
SQLSetEnvAttr , чтобы присвоить атрибуту среды SQL_ATTR_ODBC_VERSION значение SQL_OV_ODBC3_80.
Выделение общих сред для пула подключений
Среды могут совместно использоваться несколькими компонентами в одном процессе. Общая среда может использоваться более чем одним компонентом одновременно. Если компонент использует общую среду, он может использовать соединения в составе пула, что позволяет распределять и использовать существующее соединение без повторного создания этого соединения.
Перед выделением общей среды, которую можно использовать для пула соединений, приложение должно вызвать SQLSetEnvAttr , чтобы задать SQL_CP_ONE_PER_DRIVER или SQL_CP_ONE_PER_HENV атрибуту среды SQL_ATTR_CONNECTION_POOLING. SQLSetEnvAttr в этом случае вызывается с параметром енвиронменсандле , для которого задано значение null, что делает атрибут атрибутом уровня процесса.
После включения пула соединений приложение вызывает функцию SQLAllocHandle с аргументом параметром handletype , для которого задано значение SQL_HANDLE_ENV. Среда, выделенная этим вызовом, будет неявной общей средой, так как включена поддержка пулов соединений.
При выделении общей среды используемая среда не определяется до тех пор, пока не будет вызван функцию SQLAllocHandle с параметром handletype из SQL_HANDLE_DBC. На этом этапе диспетчер драйверов пытается найти существующую среду, соответствующую атрибутам среды, запрошенным приложением. Если такой среды не существует, она создается как общая среда. Диспетчер драйверов поддерживает счетчик ссылок для каждой общей среды. При первом создании среды счетчику присваивается значение 1. Если найдена соответствующая среда, в приложение возвращается маркер этой среды, а число ссылок увеличивается. Выделенный таким образом обработчик среды можно использовать в любой функции ODBC, которая принимает в качестве входного аргумента обработчик среды.
Выделение дескриптора инструкции
чтобы запросить маркер инструкции, приложение подключается к источнику данных, а затем вызывает функцию sqlallochandle перед отправкой инструкций SQL. В этом вызове параметром handletype должно быть установлено в значение SQL_HANDLE_STMT и инпусандле должны быть установлены в маркер соединения, возвращенный вызовом функцию SQLAllocHandle , который выделил этот обработчик. Драйвер выделяет память для данных инструкции, связывает обработчик инструкции с указанным соединением и передает значение связанного с ним обработчика обратно в * аутпусандлептр. Приложение передает значение * аутпусандлептр во всех последующих вызовах, требующих маркер оператора. Дополнительные сведения см. в разделе Выделение маркера инструкции.
Когда дескриптор инструкции выводится, драйвер автоматически выделяет набор из четырех дескрипторов и назначает дескрипторы для таких дескрипторов атрибутам операторов SQL_ATTR_APP_ROW_DESC, SQL_ATTR_APP_PARAM_DESC, SQL_ATTR_IMP_ROW_DESC и SQL_ATTR_IMP_PARAM_DESC. Они называются неявно выделенными дескрипторами. Сведения о том, как явно выделить дескриптор приложения, см. в следующем разделе "Выделение дескриптора дескриптора".
Выделение дескриптора соединения
Дескриптор соединения предоставляет доступ к таким сведениям, как допустимые операторы и дескрипторы дескрипторов для соединения, а также указывает, открыта ли транзакция в данный момент. Общие сведения о дескрипторах подключений см. в разделе Handles Connections.
Чтобы запросить обработчик соединения, приложение вызывает функцию SQLAllocHandle с параметром handletype SQL_HANDLE_DBC. Аргументу инпусандле присваивается маркер среды, возвращенный вызовом функцию SQLAllocHandle , который выделил этот обработчик. Драйвер выделяет память для сведений о соединении и передает значение связанного с ним маркера обратно в * аутпусандлептр. Приложение передает значение * аутпусандлептр во всех последующих вызовах, для которых требуется маркер подключения. Дополнительные сведения см. в разделе Выделение маркера подключения.
Диспетчер драйверов обрабатывает функцию функцию SQLAllocHandle и вызывает функцию функцию SQLAllocHandle драйвера, когда приложение вызывает SQLConnect, SQLBrowseConnect или SQLDriverConnect. (Дополнительные сведения см. в разделе Функция SQLConnect.)
Если атрибут среды SQL_ATTR_ODBC_VERSION не задан до вызова функцию SQLAllocHandle для выделения маркера соединения в среде, вызов для выделения соединения ВОЗВРАТИТ значение SQLSTATE HY010 (ошибка последовательности функций).
Когда приложение вызывает функцию SQLAllocHandle с аргументом инпусандле , для которого задано значение SQL_HANDLE_DBC а также задает общий обработчик среды, диспетчер драйверов пытается найти существующую общую среду, соответствующую атрибутам среды, заданным приложением. Если такой среды не существует, создается одна из них со счетчиком ссылок (поддерживаемым диспетчером драйверов), равным 1. Если найдена соответствующая общая среда, этот маркер возвращается приложению, а его число ссылок увеличивается.
Фактическое соединение, которое будет использоваться, не определяется диспетчером драйверов до тех пор, пока не будет вызван SQLConnect или SQLDriverConnect . Диспетчер драйверов использует параметры соединения в вызове SQLConnect (или ключевые слова подключения в вызове SQLDriverConnect) и атрибуты соединения, заданные после выделения соединения, чтобы определить, какое подключение в пуле следует использовать. Дополнительные сведения см. в разделе Функция SQLConnect.
Выделение дескриптора среды
Дескриптор среды предоставляет доступ к глобальной информации, такой как допустимые дескрипторы соединений и активные дескрипторы подключений. Общие сведения о дескрипторах среды см. в разделе дескрипторы среды.
Чтобы запросить обработчик среды, приложение вызывает функцию SQLAllocHandle с параметром handletype SQL_HANDLE_ENV и инпусандле SQL_NULL_HANDLE. Драйвер выделяет память для сведений о среде и передает значение связанного с ним маркера обратно в аргумент * аутпусандлептр . Приложение передает значение * аутпусандле во всех последующих вызовах, требующих аргумента обработчика среды. Дополнительные сведения см. в разделе Выделение маркера среды.
Если в обработчике среды диспетчера драйверов уже существует обработчик среды драйвера, функцию SQLAllocHandle с параметром handletype SQL_HANDLE_ENV не вызывается в этом драйвере при подключении, только функцию SQLAllocHandle с параметром handletype SQL_HANDLE_DBC. Если обработчик окружения драйвера не существует в обработчике диспетчера драйверов, то при подключении к драйверу первого маркера подключения среды в драйвере функцию SQLAllocHandle с параметром handletype SQL_HANDLE_ENV и функцию SQLAllocHandle с параметром handletype SQL_HANDLE_DBC.
Когда диспетчер драйверов обрабатывает функцию функцию SQLAllocHandle с параметром handletype SQL_HANDLE_ENV, она проверяет ключевое слово Trace в разделе [ODBC] сведений о системе. Если задано значение 1, диспетчер драйверов включает трассировку для текущего приложения. Если установлен флаг трассировки, трассировка запускается, когда первый обработчик среды выделяется и заканчивается при освобождении последнего обработчика среды. Дополнительные сведения см. в разделе Настройка источников данных.
После выделения обработчика среды приложение должно вызвать SQLSetEnvAttr в обработчике среды, чтобы задать атрибут среды SQL_ATTR_ODBC_VERSION. Если этот атрибут не задан до вызова функцию SQLAllocHandle для выделения маркера соединения в среде, вызов для выделения соединения ВОЗВРАТИТ значение SQLSTATE HY010 (ошибка последовательности функций). Дополнительные сведения см. в разделе Объявление версии ODBC приложения.
Синтаксис
Ошибки выделения памяти для обработчиков среды
Выделение среды выполняется как в диспетчере драйверов, так и в пределах каждого драйвера. Ошибка, возвращаемая функцией функцию SQLAllocHandle с параметром handletype SQL_HANDLE_ENV, зависит от уровня, в котором произошла ошибка.
Если диспетчеру драйверов не удается выделить память для * аутпусандлептр при вызове функцию SQLAllocHandle с параметром handletype SQL_HANDLE_ENV или если приложение предоставляет указатель null для аутпусандлептр, функцию SQLAllocHandle возвращает SQL_ERROR. Диспетчер драйверов устанавливает для *аутпусандлептр значение SQL_NULL_HENV (если только приложение не предоставил пустой указатель, который возвращает SQL_ERROR). Отсутствует Handle, с помощью которого можно связать дополнительные диагностические сведения.
Диспетчер драйверов не вызывает функцию выделения среды на уровне драйвера, пока приложение не вызовет SQLConnect, SQLBrowseConnect или SQLDriverConnect. Если ошибка возникает в функции функцию SQLAllocHandle на уровне драйвера, то функция SQLConnect, SQLBrowseConnect или SQLDriverConnect диспетчера драйверов возвращает SQL_ERROR. Структура диагностических данных содержит значение SQLSTATE IM004 (сбой драйвера функцию SQLAllocHandle ). Ошибка возвращается для маркера соединения.
Дополнительные сведения о потоке вызовов функций между диспетчером драйверов и драйвером см. в разделе Функция SQLConnect.
Возвращаемое значение
SQL_SUCCESS, SQL_SUCCESS_WITH_INFO, SQL_INVALID_HANDLE или SQL_ERROR.
При выделении маркера, отличного от обработчика среды, если функцию SQLAllocHandle возвращает SQL_ERROR, он устанавливает аутпусандлептр в значение SQL_NULL_HDBC, SQL_NULL_HSTMT или SQL_NULL_HDESC в зависимости от значения параметром handletype, если только аргумент OUTPUT не является пустым указателем. Затем приложение может получить дополнительные сведения из структуры диагностических данных, связанной с маркером в аргументе инпусандле .
Диагностика
Когда функцию SQLAllocHandle возвращает SQL_ERROR или SQL_SUCCESS_WITH_INFO, связанное значение SQLSTATE может быть получено путем вызова SQLGetDiagRec с соответствующим параметром handletype и Handle , для которых задано значение инпусандле. Для аргумента аутпусандле могут возвращаться SQL_SUCCESS_WITH_INFO (но не SQL_ERROR). В следующей таблице перечислены значения SQLSTATE, обычно возвращаемые функцией функцию SQLAllocHandle , и объясняется каждый из них в контексте этой функции. Нотация "(DM)" предшествует описаниям SQLSTATE, возвращаемым диспетчером драйверов. Код возврата, связанный с каждым значением SQLSTATE, имеет SQL_ERROR, если не указано иное.
Соединение с базой данных в ODBC
Цель работы: изучить функции ODBC для соединения с базой данных, а также функции для получения информации о драйвере и источнике данных, приобрести навыки использования данных функций при разработке клиентских приложений баз данных.Порядок выполнения работы
1.Ознакомиться с концепцией ODBC.
2. Изучить программный интерфейс функций SQLAllocEnv, SQLFreeEnv, SQLAllocConnect, SQLFreeConnect, SQLConnect, SQLDisconnect, а также функций SQLGetInfo и SQLGetFunctions.
3. Написать на языке программирования высокого уровня C/C++ программу, которая устанавливает соединение с источником данных, получает определенную вариантом задания информацию о драйвере и источнике данных, разъединяет соединение с источником данных.
4. Запустить ODBC-администратор и с его помощью выбрать ODBC-драйвер для используемого в программе источника данных.
5. Выполнить программу, разработанную в п.3.
6. Оформить отчет о проделанной работе.
Содержание отчета
Краткое описание используемых функций ODBC;
Краткое описание программы;
Листинг программы;
Результаты выполнения программы;
Основные сведения
Функция SQLAllocEnv
Данная функция распределяет память для идентификатора среды и инициализирует интерфейс ODBC для использования прикладной программой.
Функция SQLAllocEnv имеет следующий синтаксис:
где phenv – адрес идентификатора среды (выходной параметр типа HENV FAR *).
Поскольку в рамках одной среды можно установить произвольное число соединений, для каждой прикладной программы достаточно выделить только один идентификатор среды.
Функция SQLFreeEnv
Данная функция освобождает идентификатор среды, а также всю назначенную ему память. Функция SQLFreeEnv имеет следующий синтаксис:
где henv – идентификатор среды (входной параметр типа HENV).
Функция SQLAllocConnect
Данная функция распределяет память для идентификатора соединения в рамках среды, определенной с помощью идентификатора henv. Функция SQLAllocConnect имеет следующий синтаксис:
RETCODE SQLAllocConnect(henv, phdbc)
Описание параметров для данной функции приведено в следующей таблице.
Функция SQLFreeConnect
Данная функция освобождает идентификатор соединения и всю связанную с ним память. Функция SQLFreeConnect имеет следующий синтаксис:
где hdbc – идентификатор соединения (входной параметр типа HDBC).
Функция SQLConnect
Функция SQLConnect загружает драйвер базы данных и устанавливает соединение с источником данных. Функция SQLConnect имеет следующий синтаксис:
RETCODE SQLConnect(hdbc, szDSN, cbDSN, szUID, cbUID, szAuthStr, cbAuthStr)
Описание параметров для данной функции приведено в следующей таблице.
Если источник данных не требует имени пользователя (пароля), то нулевое значение или пустая строка должны быть переданы в szUID (szAuthStr), нулевое значение или SQL_NTS - в cbUID (cbAuthStr).
Функция SQLDisconnect
Данная функция закрывает соединение с источником данных. Функция SQLDisconnect имеет следующий синтаксис:
где hdbc – идентификатор соединения (входной параметр типа HDBC).
Функция SQLGetInfo
Данная функция возвращает общую информацию о драйвере и источнике данных, соответствующих заданному идентификатору соединения. Функция SQLGetInfo имеет следующий синтаксис:
RETCODE SQLGetInfo(hdbc, fInfoType, rgbInfoValue, cbInfoValueMax, cbInfoValue)
Описание параметров для данной функции приведено в следующей таблице.
Функция SQLGetFunctions
Данная функция определяет, поддерживает ли драйвер заданную функцию ODBC. Функция SQLGetFunctions имеет следующий синтаксис:
RETCODE SQLGetFunctions(hdbc, fFunction, pfExists)
Коды возврата функций ODBC
Код возврата
Описание
SQL_SUCCESS
Функция выполнена успешно. Информация об ошибке для возврата отсутствует.
SQL_SUCCESS_WITH_INFO
Функция выполнена успешно, однако имеется некоторая дополнительная информация о выполнении функции
SQL_NO_DATA_FOUND
Все строки результирующего множества извлечены.
SQL_ERROR
Ошибка в процессе выполнения данной функции
SQL_INVALID_HANDLE
Недействительный идентификатор
SQL_STIL_EXECUTING
Функция выполняется асинхронно и все еще находится в процессе выполнения
SQL_NEED_DATA
При подготовке или выполнении какого-либо оператора драйвер установил, что прикладная программа должна определить не менее одного значения параметра.Функция SQLError
Для получения дополнительной информации в случае возникновения ошибки (при этом кодом завершения ODBC-функции является значение SQL_ERROR SQL_SUCCESS_WITH_INFO) следует воспользоваться функцией SQLError. Функция SQLError имеет следующий синтаксис:
RETCODE SQLError(henv, hdbc, hstmt, szSqlState, pfNativeError, szErrorMsg, cbErrorMsgMax, cbErrorMsg)
Описание параметров для данной функции приведено в следующей таблице.
Методические указания
Обобщенный алгоритм использования ODBC в прикладных программах представлен ниже (в скобках указаны основные используемые функции).
Фаза инициализации
Шаг 1. Назначение идентификатора среды (SQLAllocEnv)
Шаг 2. Назначение идентификатора соединения (SQLAllocConnect)
Шаг 3. Соединение с сервером (SQLConnect)
Шаг 4. Назначение идентификатора оператора (SQLAllocStmt)
Фаза обработки SQL операторов
Шаг 5. Выполнение оператора (SQLExecDirect, SQLPrepare, SQLExecute)
Шаг 6. Выборка данных (SQLFetch, SQLBindCol, SQLGetData, SQLExtendedFetch)
Фаза завершения
Шаг 7. Освобождение идентификатора оператора (SQLFreeStmt)
Шаг 8. Разрыв соединения с сервером (SQLDisconnect)
Шаг 9. Освобождение идентификатора соединения (SQLFreeConnect)
Шаг 10. Освобождение идентификатора окружения(SQLFreeEnv)
Вышеприведенный алгоритм является общим для лабораторных работ NN 3-5. В данной лабораторной работе используется алгоритм, включающий шаги 1, 2, 3, использование функций SQLGetFunctions и SQLGetInfo, шаги 8, 9, 10 в приведенном порядке.
Для возможности работы с функциями ODBC в программу на языках С или С++ необходимо включить заголовочный файл sql.h директивой
Варианты заданий
Задание типа А: Определить, поддерживает ли драйвер заданную функцию.
1. SQLAllocEnv, SQLMoreResults, SQLDriverConnect, SQLRowCount;
2. SQLFreeEnv, SQLColumnPrivileges, SQLStatistics, SQLParamData;
3. SQLAllocConnect, SQLExtendedFetch, SQLDrivers, SQLPutData;
4. SQLFreeConnect, SQLSetStmtOption, SQLColumns, SQLTransact;
5. SQLConnect, SQLGetCursorName, SQLTables, SQLGetTypeInfo;
6. SQLDisconnect, SQLSetConnectOption, SQLProcedure, SQLColAttributes;
7. SQLAllocStmt, SQLDataSources, SQLGetConnectOption, SQLCancel;
8. SQLFreeStmt, SQLSpecialColumns, SQLParamOption, SQLGetInfo;
9.SQLExecDirect, SQLTablePrivileges, SQLDescribeCol, SQLNativeSql;
10. SQLExecute, SQLGetData, SQLSetCursorName, SQLGetFunctions;
11. SQLPrepare, SQLFetch, SQLProcedureColumns, SQLPrimaryKeys;
12. SQLBindCol, SQLForeignKeys, SQLNumResultCols, SQLSetPos.
Задание типа Б: Выбрать информацию об источнике данных. Тип выбираемых данных помечается символами S, B, N, заключенными в круглые скобки. Тип данных, отмеченный символом S, соответствует символьной строке, а символом N – числовому значению. Тип данных, отмеченный символом ?, является логическим. При этом надо определить, поддерживает ли источник данных указанные возможности.
1. Имя текущей базы данных (S);
3. Имя драйвера (S);
4. Курсор с выборкой следующей строки (?);
5. Курсор с выборкой первой строки (?);
6. Курсор с выборкой последней строки (?);
7. Курсор с выборкой предыдущей строки (?);
8. Курсор с выборкой N-й строки (?);
9. Курсор с выборкой N-й строки по отношению к текущей позиции (?);
10. Оператор позиционного удаления (?);
11. Оператор позиционной модификации (?);
12. Число активных операторов в соединении (N).
Лабораторная работа N 4
Выполнение операторов SQL в ODBC
Цель работы: изучить функции ODBC для выполнения SQL-операторов, приобрести навыки использования данных функций при разработке клиентских приложений баз данных.
Порядок выполнения работы и варианты заданий
1. Изучить программный интерфейс функций SQLAllocStmt, SQLFreeStmt, SQLExecDirect, SQLPrepare, SQLExecute, SQLBindParameter.
2. Написать на языке программирования высокого уровня C/C++ программу для создания и заполнения данными таблицы в соответствии с заданием лабораторной работы N 2. Пользовательский интерфейс программы должен включать формы с полями ввода для занесения информации в таблицу. При нечетном номере варианта задания использовать прямое выполнение SQL-оператора, а при четном – подготавливаемое.
3. Запустить ODBC-администратор и с его помощью выбрать ODBC-драйвер для используемого в программе источника данных.
4. Выполнить программу, разработанную в п.2.
5. Оформить отчет о проделанной работе.
Основные сведения
Функция SQLAllocStmt
Данная функция распределяет память для идентификатора оператора в рамках определенного соединения. Функция SQLAllocStmt имеет следующий синтаксис:
RETCODE SQLAllocStmt(hdbc, phstmt)
Описание параметров для данной функции приведено в следующей таблице.
Функция SQLFreeStmt
Данная функция выполняет следующие действия:
останавливает обрабатываемые SQL-операторы, связанные с заданным идентификатором оператора;
закрывает открытые курсоры, имеющие отношение к заданному идентификатору оператора;
отбрасывает ожидаемые результаты;
освобождает все ресурсы, связанные с заданным идентификатором оператора.
RETCODE SQLFreeStmt(hstmt, fOption)
Описание параметров для данной функции приведено в следующей таблице.
Опция SQL_CLOSE закрывает курсор и отбрасывает все ожидаемые результаты. Опция SQL_DROP освобождает идентификатор оператора и все связанные с ним ресурсы, а также выполняет действия предыдущей опции. Опция SQL_UNBIND освобождает (“отвязывает”) все столбцы, используемые соответствующей функцией SQLBindCol. Опция SQL_RESET_PARAMS освобождает все параметры, используемые соответствующей функцией SQLBindParameter. Перечисленные опции используются применительно к заданному идентификатору оператора.
Функция SQLExecDirect
Данная функция выполняет SQL-оператор. Если в операторе существуют какие-либо параметры, то при выполнении используются их текущие значения. Функция SQLExecDirect имеет следующий синтаксис:
RETCODE SQLExecDirect(hstmt, szSqlStr, cbSqlStr)
Описание параметров для данной функции приведено в таблице.
Аргумент
Тип
Использование
Описание
hstmt
HSTMT
Ввод
Идентификатор оператора
szSqlStr
UCHAR FAR*
Ввод
Строка, содержащая SQL-оператор (адрес)
cbSqlStr
SDWORD
Ввод
Длина строки szSqlStr
Функция SQLExecDirect представляет самый быстрый способ запустить SQL-оператор при одноразовом выполнении.
Функция SQLPrepare
Данная функция подготавливает SQL-строку для выполнения. Функция SQLPrepare имеет следующий синтаксис:
RETCODE SQLPrepare(hstmt, szSqlStr, cbSqlStr)
Данная функция имеет такие же параметры, что и функция SQLExecDirect.
Функция SQLExecute
Данная функция выполняет подготовленный SQL-оператор. Если в операторе существуют какие-либо параметры, то при выполнении используются их текущие значения. Функция SQLExecute имеет следующий синтаксис:
где hstmt – идентификатор оператора (входной параметр типа HSTMT).
Перед вызовом функции SQLExecute должна быть выполнена функция SQLPrepare.
Функция SQLBindParameter
Данная функция связывает параметр SQL-оператора с буфером, где хранится его значение. Функция SQLBindParameter имеет следующий синтаксис:
RETCODE SQLBindParameter(hstmt, ipar, fParamType, fCType, fSqlType, cbColDef, ibScale, rgbValue, cbValueMax, pcbValue)
Описание параметров для данной функции приведено в следующей таблице.
Аргумент
Тип
Использование
Описание
hstmt
HSTMT
Ввод
Идентификатор оператора
ipar
UWORD
Ввод
Номер параметра
fParamType
SWORD
Ввод
Тип параметра
fCType
SWORD
Ввод
С-тип данных параметра
fSqlType
SWORD
Ввод
SQL-тип данных параметра
cbColDef
UDWORD
Ввод
Точность столбца источника данных
ibScale
SWORD
Ввод
Размер столбца источника данных
rgbValue
PTR
Ввод/вывод
Буфер значения параметра (адрес)
CbValueMax
SDWORD
Ввод
Максимальная длина буфера rgbValue
PcbValue
SDWORD FAR*
Ввод/вывод
Буфер значения длины параметра (адрес)
Параметры в SQL-операторах отмечаются маркером ?. Пример: INSERT INTO Emp(empid, firstname) VALUES (. ).
Нумерация параметров начинается с 1. Тип параметра fParamType может принимать одно из трех значений: SQL_PARAM_INPUT, SQL_PARAM_INPUT_OUTPUT или SQL_PARAM_OUTPUT. Значение SQL_PARAM_INPUT используется для всех параметров, которые не включены в процедуру, а также для процедур, использующих параметры ввода. Значение SQL_PARAM_INPUT_OUTPUT маркирует параметр ввода/вывода в процедуре. Значение SQL_PARAM_OUTPUT маркирует значение возврата или параметр вывода в процедуре.
С-тип данных - это тип данных, из которого конвертируются данные. C-тип данных параметра может быть одним из следующих значений: SQL_C_BINARY, SQL_C_BIT, SQL_C_CHAR, SQL_C_DATE, SQL_C_DEFAULT, SQL_C_DOUBLE, SQL_C_FLOAT, SQL_C_SLONG, SQL_C_SSHORT, SQL_STINYINT, SQL_C_TIME, SQL_C_TIMESTAMP, SQL_C_ULONG, SQL_C_USHORT, SQL_C_UTINYINT, SQL_C_DEFAULT.
SQL-тип данных - это тип данных, в который конвертируются данные. Он должен совпадать с SQL-типом соответствующего столбца. SQL-тип данных может быть одним из следующих значений: SQL_BIGINT, SQL_BINARY, SQL_BIT, SQL_CHAR, SQL_DATE, SQL_DECIMAL, SQL_DOUBLE, SQL_FLOAT, SQL_INTEGER, SQL_LONGVARBINARY, SQL_LONGVARCHAR, SQL_NUMERIC, SQL_REAL, SQL_SMALLINT, SQL_TIME, SQL_TIMESTAMP, SQL_TINYINT, SQL_VARBINARY, SQL_VARCHAR.
Пример вызова функции SQLBindParameter:
rc=SQLBindParameter(hstmt, 1, SQL_PARAM_INPUT, SQL_C_CHAR, SQL_CHAR, TEST_LEN, 0, szTEST, 0, &cbTEST);
Демократия — это процесс, в ходе которого люди свободно выбирают козла отпущения. Лоренс Питер
ещё >>Читайте также: