Значения атрибутов устанавливаются и извлекаются с помощью набора функций, объявления которых приведены на рис. 19.22. Функции SQLGetEnvAttr (), SQLGetConnectAttr () и SQLGetStmtAttr О считывают значения атрибутов, а функции SQLSetEnvAttr о , SQLSetConnectAttr () и SQLSetStmtAttr () их устанавливают. Во всех этих функциях конкретный обрабатываемый атрибут идентифицируется собственным кодом.

/* Получение значения указанного атрибута среды SQL */ short SQLGetEnvAttr(

long envHdl, /* Входной: дескриптор среды */

long attrCode, /* Входной: целочисленный код атрибута */

void *rtnVal, /* Выходной: буфер, в который записывается

возвращаемое значение */ long bufLen, /* Входной: длина буфера */

long *strLen) /* Выходной: указатель на буфер, в который

записывается реальная длина полученных данных */

/* Установка значения указанного атрибута среды SQL short SQLSetEnvAttr(

/* Входной: /* Входной: /* Входной: /* Входной:

long envHdl,

long attrCode,

void *attrVal,

long strLen)

дескриптор среды */ целочисленный код атрибута */ буфер с новым значением атрибута */ длина буфера */

/* Получение значения указанного атрибута сеанса подключения */ short SQLGetConnectAttr(

long connHdl, /* Входной: дескриптор сеанса */

long attrCode, /* Входной: целочисленный код атрибута */

void *rtnVal, /* Выходной: буфер, в который записывается

возвращаемое значение */ long bufLen, /* Входной: длина буфера */

long *strLen) /* Выходной: указатель на буфер, в который

записывается реальная длина полученных данных */

/* Установка значения указанного атрибута сеанса подключения */ short SQLSetConnectAttr(

дескриптор сеанса */ целочисленный код атрибута */ буфер с новым значением атрибута */ длина буфера */

трибута инструкции SQL */

дескриптор инструкции */ целочисленный код атрибута */ буфер, в который записывается возвращаемое значение */ длина буфера */ указатель на буфер, в который записывается реальная длина полученных данных */

Установка значения указанного атрибута инструкции SQL */ short SQLSetStmtAttr(

/* Входной: /* Входной: /* Входной: /* Входной:

long StmtHdl, long attrCode,

void *attrVal, long StrLen)

дескриптор инструкции */ целочисленный код атрибута */ буфер с новьш значением атрибута */ длина буфера */

Рис* ?Я22 ФунфзнСИ

че для управления атрибупзми

Хотя описанная схема работы с атрибутами может показаться сложной, на самом деле атрибутов не так уж и много. Единственный определенный стандартом CLI атрибут среды управляет интерпретацией строк, оканчивающихся нулевым символом Единственный атрибут сеанса определяет, будет ли CLI автоматически заполнять описатели параметров при подготовке инструкции SQL к выполнению. Что касается атрибутов инструкции, то они в основном управляют свойствами наборов записей Вероятно, самыми важными из определенных в CLI атрибутов являются дескрипторы четырех описателей, которые могут быть связаны с инструкцией SQL- два описателя параметров и два описателя записей.

Протокол ODBC, на котором изначально основывался стандарт SQL/CLI, включает множество других атрибутов. Например, атрибуты сеанса в ODBC могут определять сеанс как используемый только для выборки данных, устанавливать режим асинхронной обработки запросов, задавать время ожидания для запросов, направляемых серверу через указанное подключение, и т.п. Атрибуты среды в ODBC управляют автоматической трансляцией вызовов ODBC, написанных для ранних версий этого протокола. Атрибуты инструкции в ODBC задают уровень изоляции транзакций, разрешают или запрещают использование наборов записей с произвольным доступом и ограничивают количество строк в таблице результатов запроса, которые могут быть сгенерированы в ответ на запрос удаленного приложения.

Функции, возвращающие информацию о СИ

Стандарт CL1 определяет три специфические функции, которые могут использоваться для получения информации о конкретной реализации CLI. В специализированных приложениях эти функции вызываются редко. Они нужны скорее в профаммах общего назначения (таких как утилиты формирования запросов или генераторы отчетов), которым необходимо знать точные характеристики используемого профаммного интерфейса. Объявления этих трех функций приведены на рис. 19.23.

/* Получение информации о конкретной реализации CLI */ short SQLGetInfo(

long connHdl, /* Входной: дескриптор сеанса */ short mfoType, /* Входной: тип запрашиваемой информации */ void *infoval, /* Выходной: буфер для возвращаемой информации */ short bufLen, /* Входной: длина буфера */

short *infoLen) /* Выходной: указатель на буфер, в который

записывается реальная длина полученной информации */

/* Получение информации о поддержке конкретной функции CLI */ short SQLGetFunctions(

long connHdl, /* Входной: дескриптор сеанса */ short functionid, /* Входной: идентификатор функции */ short *supported) /* Выходной: указатель на буфер, в который

записывается признак того, поддерживается ли функция */

/* Получение информации о поддерживаемых типах данных */

short SQLGetTypelnfo(

long StmtHdl, /* Входной: дескриптор инструкции */ short dataType) /* Входной: запрашиваемый тип данных */

Рис 19.23. Функции си, служащие для получения информации о конкретной реализации

функция SQLGetFunctions () позволяет определить, поддерживает ли текущая реа-;]изация библиотеки CL1 конкретную функцию. Вы задаете константу, соответствующую одной из функций CL1, и в параметре supported получаете значение, указывающее, подяерживается ли эта функция. Функция SQLGetlnfo () используется для получения более подробной информации о реализации библиотеки, например: максимальная длина имен таблиц и пользователей, поддерживает ли СУБД операции внещнего объединения лли транзакции и учитьшается ли регастр символов в идентификаторах SQL.

функция SQLGetTypelnfo О используется для получения информации о поддержке конкретного типа данных или обо всех типах данных, поддерживаемых библиотекой CLL Вызов этой функции подобен запросу к системному каталогу на получение информации о типах данных. Функция возвращает набор записей, в котором каждая запись содержит информацию об одном типе данных: имя, размер, допускаются ли значения NULL и т.п.

Протокол ODBC

Как уже говорилось, первоначально Microsoft разрабатывала свой протокол ODBC для того, чтобы предоставить разработчикам приложений Windows универсальный интерфейс доступа к базам данных, не зависящий от конкретной СУБД. Эта исходная версия ODBC была положена в основу стандарта SQL/CLI, который в настоящее время является официальным стандартом ANSI/ISO для профаммньк интерфейсов SQL. Одновременно с разработкой спецификации SQL/CLI протокол ODBC был значительно расширен и модифицирован. Выпущенная компанией Microsoft версия ODBC 3.0 соответствует стандарту SQL/CL1, но значительно превосходит его по своим возможностям.

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

Структура ODBC

Сфуктура протокола ODBC изображена на рис. 19.24. Программное обеспечение ODBC состоит из фех основных уровней:

Интерфейс вызовов функций. На самом верхнем уровне ODBC находится единый профаммный интерфейс, который может использоваться всеми приложениями. Этот API реализован в виде библиотеки динамической компоновки (DLL), которая является неотъемлемой частью Windows.

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