69280

Підготовка і виконання запиту. Отримання даних. Відключення

Лекция

Информатика, кибернетика и программирование

Останнє, що додаток повинен зробити після підключення до джерела даних, але перш, ніж воно буде здатне здійснювати запити SQL, — це отримати дескриптор оператора (statement handle) або hstmt. Щоб отримати дескриптор hstmt, достаточш оголосити змінну типу SQLHSTMT і викликати функцію...

Украинкский

2014-10-02

41 KB

0 чел.

Лекція № 22

Тема: Підготовка і виконання запиту. Отримання даних. Відключення.

План

  1.  Підготовка і виконання запитів SQL
  2.  Отримання даних
  3.  Відключення від джерела даних

Підготовка і виконання запитів SQL

Останнє, що додаток повинен зробити після підключення до джерела даних, але перш, ніж воно буде здатне здійснювати запити SQL, — це отримати дескриптор оператора (statement handle) або hstmt. Щоб отримати дескриптор hstmt, достаточш оголосити змінну типу SQLHSTMT і викликати функцію SQLAllocHancUe, переду! їй як аргументи константу SQL_HANDLE__STMT і адреса оголошеною змінно» hstmt. Нижче приведений фрагмент коди, що демонструє, як це зробити:

 

SQLSTMT hstmt;

SQLRETURN re = SQLAllocHandle<SQL_HANDLE_STMT

hdbc, Shstmt);

Як тільки додаток отримає дескриптор hstmt, воно зможе передавати джерелу енних оператори SQL. Існує два разных способу організації виконання джерелом даних запиту SQL. Перший має на увазі застосування функції SQLExecDirect, другим аргументом якої є оператор SQL, як показано в прикладі, приведеному нижче. Ця функція додасть в таблицю UserMaster новий рядок даних:

SOLRETURN гс = ::SQLExecDirect(hstmt

(unsigned char*)"INSERT INTO " "UserMaster VALUES('USERLD' " "'User Name', 0)", SQL_NTS))

Другий спосіб виконання оператора має на увазі його попередню підготовку за допомогою функції SQLPrepare, а також його подальше виконання за допомогою функції SQLExecute, як показано в прикладі, приведеному нижче.

SQLRETURN re;

LPCSTR szSQL = "INSERT INTO UserMaster "

"values('UserlD2', 'Just Another User', 0) "/

if (SQL_SUCCESS == (re = ::SQLPrepare (hstmt

(unsigned char*)szSQL, SQL_NTS)))

( if (SQL_SUCCESS == (re = ::SQLExecute (hstmt)))

При частому виконанні різних операторів SQL подібна комбінація функцій SQLPrepare/SQLExecute набагато ефективніша, ніж просто виклик функції SQLExecDirect. Це пов'язано з тим, що при кожному виклику функції SQLExecDirect вираз повинен відкомпілюватися (compiled) основний DBMS. Проте при попередньому виклику функції SQLPrepare вираз відкомпілюється тільки один раз, а потім кожного разу використовуватиметься функцією SQLExecute в готовому вигляді.

Отримання даних

У попередньому розділі продемонстровані два разных способу застосування оператора SQL, що додає дані в таблицю. Але що, якщо в результаті виконання оператора SQL будуть повернені дані, і як передати їх в змінні застосування? Для цього призначена наступна група функцій ODBC. Коли функція ODBC повертає результуючий набір даних (result set) (або набір результатов— resuitset), змінні застосування необхідно пов'язати (bind) з полями повертаних даних. ODBC надає щонайширший набір різноманітних типів даних, доступних для застосування у складі застосування, що розробляється.

Якщо гнучкість додатку є одному з головних завдань проекту, то користь від застосування функцій SQLNumResultCols, SQLDescribeCol і SQLGetData в його складі буде вельми ощутима. Ці функції дозволяють розробникові створювати додатки баз даних, не піклуючись заздалегідь про те, скільки полів і якого типу повертатиме джерело даних у складі результуючого набору даних. Наприклад, ці функції можна було б використовувати у складі додатку, що дозволяє користувачеві самостійно формувати запити, передавані базі даних. У зв'язку з динамічним характером цього застосування йому не буде заздалегідь відома кількість і тип даних полів, повертаних в результаті їх виконання.

Оскільки ж додаток може дізнатися, які саме дані були повернені в результаті запиту, якщо це не було визначено заздалегідь, до виконання запиту? Додаток використовує функції, описані в попередньому розділі, для компіляції і виконання призначених для користувача операторів SQL. Потім ODBC повертає дескриптор результуючого набору даних. Але додатку нічого не відомо ні про кількість полів, повернених в результуючому наборі даних, ні про їх тип. Так, щоб визначити, скільки саме полів (стовпців) було повернено в результуючому наборі даних, додаток звертається до функції SQLNumResultCols. Потім воно викликає функцію SQLNumResultCols для кожного з полів, щоб з'ясувати тип розташованих в них даних. Як тільки тип даних певного поля стає відомий, застосовується функція SQLGetData, що дозволяє витягувати з нього значення. Безумовно, це опис вельми схемний, проте воно дає загальне уявлення про процес застосування цих функцій. Більш детально дана тема розглядається на прикладі другого і третього демонстраційних додатків цього розділу.

Цілком очевидно, що такий рівень гнучкості, який описаний вищим, потрібний зовсім не кожному застосуванню. Більшість розробників баз даних використовують оператори SQL, жорстко задані в коді застосування, а отже, їм не потрібно звертатися до ODBC, щоб з'ясувати тип даних повертаних в результуючому наборі даних. В цьому випадку для витягання даних з результуючого набору даних і привласнення їх змінним додатку можна скористатися функціями SQLBindCol і SQLFetch. Функція SQLBindCol, що відповідає за скріплення даних, дозволяє вказати номер поля результуючого набору даних, тип даних цього поля результуючого набору даних, а також адресу змінної додатку, яка отримає ці дані при виклику функції SQLFetch, що відповідає за вибірку зв'язаних даних.

Звернете увагу, немає ніякої необхідності зв'язувати всі поля, досить зв'язати лише ті поля, дані яких необхідно передати в змінні. Функцію SQLBindCol необхідно викликати один раз, але для кожного використовуваного поля, а функцію SQLFetch після цього можна викликати багато раз, при кожній необхідності прочитати результуючий набір даних. Нижче приведений приклад застосування обох функцій для отримання даних з результуючого набору даних. Цей фрагмент коди має на увазі, що оператори SQL, організуючі повернення результуючого набору даних, вже були виконані:

#define LEN_USERID 16

SDWORD cb;

char szUserID[LEN_USERID];

if (SQL_SUCCESS == (re = SQLBindCol(hstmt, 1

SQL_C_CHAR, szUserlD, LENJJSERID &cb))) {

if (SQL_SUCCESS == (re = SQLFetch(hstmt))) {

// Тепер szUserlD містить значення з першого

// поля поверненого набору результатів.

 

Відключення від джерела даних

Як тільки підключення до джерела даних стане непотрібним, від нього необхідно відключитися (за допомогою функції SQLDisconnect), а також звільнити всі дескриптори, які були для цього створені. Код "очищення" ("cleanup") для приведеного вище прикладу міг би виглядати таким чином:

if (henv)

{

if (hdbc)

{

if (blsConnected)

(

if <hstmtj

{ ::SQLFreeHandle{SQL_HANDLE_STMT, hstmt);

}

::SQLDisconnect(hdbc);

blsConnected = FALSE;

}

::SQLFreeHandle{SQL_HANDLE_DBC, hdbc);

hdbc = NULL;

}

::SQLFreeHandle(SQL_HANDLE_ENV, henv); henv = NULL;

}

Отже, вивчивши основи використання ODBC, розглянемо в наступному розділі демонстраційне застосування.


 

А также другие работы, которые могут Вас заинтересовать

45270. Принципы построения сети сотовой связи на основе CDMA (многостанционный доступ с кодовым разделением каналов) 403 KB
  Каналы трафика и управления В CDM каналы для передачи от базовой станции к мобильной станции называются прямыми Forwrd. В обратном направлении подвижные станции отвечают асинхронно без использования пилотного сигнала при этом уровень мощности приходящий к базовой станции от каждой подвижной станции одинаков. Состав прямых каналов Пилотный канал Pilot Chnnel предназначен для установления начальной синхронизации контроля уровня сигнала базовой станции по времени частоте и фазе идентификации базовой станции. Канал синхронизации SCH ...
45271. Сеть общеканальной сигнализации ОКС- 7. Принципы построения, режимы 47.5 KB
  Сеть общеканальной сигнализации ОКС 7. Рисунок по структуре протоколов В системе ОКС7 сигнальные сообщения передаются по отдельными звеньям сигнализации причем одно звено сигнализации может передавать сигнальные сообщения для большого числа разговорных каналов. Для обеспечения избыточности в другой системе ИКМ как правило предоставляется дополнительный канал сигнализации. ОКС7 имеет собственную сеть сигнализации независимую от разговорной сети.
45272. Уровни и подсистемы ОКС-7 55 KB
  Верхний уровень ОКС7 включает подсистемы: обеспечивание транзакций TCP пользовательские ISUP MUP HUP сервисные элементы прикладного уровня SL уровень подвижной связи стандарта GSMMP прикладная подсистема интеллектуальной сети INP подсистема эксплуатации техническое обслуживание и административное управление OMT. Подсистема пользователя ОКС7 обеспечивает функции сигнализации необходимые для обслуживания вызовов в телефонной сети и в сети ISDN а также для поддержки дополнительных услуг в ISDN. Подсистема...
45273. Подсистема передачи сообщений (МТР) ОКС-7 54.5 KB
  Для передачи сигнальной информации между пунктами сигнализации и для управления SCCP. МТР1: определяет физические электрические и функциональные характеристики канала передачи данных для звена сигнализации. МТР2: определяет функции и процедуры относящиеся к передаче сигнальных сообщений по звену сигнализации между двумя напрямую связанными пунктами сигнализации. Сочетание МТР1 и МТР2 организует звено сигнализации для передачи...
45274. Подсистема пользователя сети ОКС-7 с интеграцией служб (ISUP). Сигнальные сообщения при установлении соединения. Сценарий процесса установления соединения 151.5 KB
  Любое сообщение включает ряд параметров. Предусмотрены следующие 3 категории: Фиксированные обязательные параметры всегда включаются в сообщение и имеют фиксированную длину при этом позиция длина и порядок расположения обязательных параметров однозначно определяются типом сообщения поэтому их название и индикаторы длины не включаются в сообщение. Переменные обязательные параметры всегда включаются в сообщение но имеют переменную длину. Расположение переменных обязательных параметров в сообщении ...
45275. Коммутация каналов, пакетов, сообщений 35.5 KB
  Сеть связи switching network представляет собой совокупность технических средств предназначенных для передачи приема информации и состоит из абонентских устройств АУ линий связи и коммутационных узлов КУ.1 – Фрагмент сети связи Лицо пользующееся абонентским устройством для передачи приема информации называется абонентом. Для передачи приема информации между удаленными коммутационными узлами используют каналы связи которые образуются при помощи многоканальных систем передачи. Он характеризуется тем что канал между передатчиком и...
45276. Принципы построения цифровых коммутаторов (пространственный, временной). Адресная и информационная память 201.5 KB
  Номер ячейки памяти определяет номер канала на выходе а адрес который в ней записан определяет ту ячейку ИП которую нужно открыть на данном канальном интервале. Схема коммутации и управляющей памяти является общей. Число разрядов в ячейках управляющей памяти равно N=log n. В каждой ячейке управляемой памяти записываются адреса схем И которые необходимо открыть в период канального интервала соответствующего номеру ячейки управляющей памяти.
45277. Обобщенная структурная схема цифровой АТС. Преобразование аналогового сигнала в цифровую форму 87 KB
  Преобразование аналогового сигнала в цифровую форму. МАЛ содержит абонентские комплекты АК взаимодействие оборудования АТСЭ с оконечным устройством пользователя и мультиплексор цифрового тракта Мх мультиплексирование индивидуальных Вканалов МЦК содержит коммутационное поле КПпроизводит коммутацию любого канального интервала time slot любого входящего тракта с любым канальным интервалом любого исходящего тракта линейные комплекты ЛКтобеспечивает синхронизацию ИКМ трактов и преобразование линейного сигнала генератор...
45278. Идеология и архитектура Softswitch коммутатора 135.5 KB
  Идеология и архитектура Softswitch коммутатора. Рисунок по архитектуре Softswitch является носителем интеллектуальных возможностей сети который координирует управление обслуживанием вызовов сигнализацию и функции обеспечивающие установление соединения через одну или несколько сетей. Фактически Softswitch остается тем же привычным коммутационным узлом но без цифрового коммутационного поля кросса и т. Термин Softswitch был придуман при разработке интерфейса между интерактивной речевой системой IVR и АТС с коммутацией каналов в...