Читать онлайн «Мир InterBase. Архитектура, администрирование и разработка приложений баз данных в InterBase/FireBird/Yaffil». Страница 53

"query interface [IDBSchemaRowset]",spSR.m_hr);

IUnknownPtr spUnk;

HRESULT hr=spSR->GetRowset(NULL,DBSCHEMA_TABLES,0,NULL,

IID_IUnknown,0,NULL,&spUnk.ref_ptr());

if(FAILED(hr))

t_ole_error::throw_disp_error(hr,"get tables list");

//подключаем полученный набор к курсору

t_db_cursor cursor;

_THROW_OLEDB_FAILED(cursor,attach(spUnk))

//получаем описание полей результирующего

//множества (набора данных)

t_db_row row;

_THROW_OLEDB_FAILED(cursor,describe(row))

//печатаем содержимое набора

while(cursor.fetch(row)==S_OK)

{

for(t_db_row::size_type i=0;i!=row.count;++i)

cout<<row.columns(i).name<<":"<<row[i].as_string<<endl ;

cout<<endl;

}//while

//проверяем причину выхода из цикла

_THROW_OLEDB_FAILED(cursor,m_last_result)

}

catch(const exception& exc){

cout<<"error:"<<exc.what()<<endl;

}

Команда используется для выполнения SQL-запросов к базе данных Важно не путать команду, которая является СОМ-объектом, с текстом команды, который представляет собой строку. Обычно команды используют для описания данных, например для создания таблицы и предоставления привилегий, и манипуляции данными, например для обновления и удаления строк Особый случай манитчя- ции данными - создание набора строк (примером служит оператор SQL SELECT).

Спецификация OLE DB определяет гибкий набор интерфейсов для выполнения и обработки результатов SQL-запросов. Определяется так последовательность шагов:

* Создание команды.

* Установка текста запроса.

* Подготовка запроса.

* Подготовка параметров запроса.

* Установка свойств результирующего множества (набора данных).

* Выполнение запроса.

Как уже было отмечено ранее, объект команды создается объектом сессии.

С помощью отдельной сессии можно создать много команд

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

Примеры создания команд.

ADODB

Dim сn As New ADODB.Connection

сn.Open "file name=d:\database\employee.ibp"

Dim cmd As New ADODB.Command cmd.ActiveConnection = сn

C++

t_db_data_source сn;

_THROW_OLEDB_FAILED(cn, attach(

"file name=d:\\database\\employee.ibp"));

t_db_session session;

_THROW_OLEDB_FAILED(session,create(en));

t_db_command cmdl,cmd2;

//Создаем команду традиционным способом,

//используя объект C++ сессии

_THROW_OLEDB_FAILED(cmdl,create(session));

//Команду также можно создать, обладая

//только указателем на lUnknown OLE DB-сессии.

//Это более подходящий способ для СОМ-объектов

IUnknownPtr spSession(session session_obj());

_THTOW_OLEDB_FAILED(cmd2,create(spSession));

Если команда только что создана, она еще не содержит текста. Поэтому текст SQL-запроса нужно установить

Пример установки текста запроса:

ADODB

cmd.Command.Text = "select x from job"

При этом IBPrivider сбрасывает флаг подготовленности команды и очищает список параметров Как это ни странно, здесь могут происходить ошибки:

* Команда обнаружит смешанное использование параметров - именованных " param" и неименованных, обозначаемых вопросительным знаком ('"?")

* Сбой преобразования SQL-запросов из ODBC-диалекта в вид, пригодный для передачи на сервер

Все действия, связанные с установкой текста команды, осуществляются локально, т. е. обращение к серверу базы данных не производится.

Если пользователю нужна информация о наборе рядов, который она создаст, то команду нужно подготовить:

C++

t_db_row row;

_THROW_OLEDB_FAILED (cmd, prepare("select * from iob",&row))

Поскольку с точки зрения взаимодействия с InterBase подготовка представляет собой передачу текста SQL-запроса серверу базы данных, то этот этап будет выполнен всегда - либо явным указанием пользователя, либо самой командой. При этом повторный вызов операции подготовки для одного и того же текста запроса игнорируется. Реализация команды провайдера для InterBase не осуществляет переподготовку запроса при повторном выполнении команды, поэтому явная подготовка с целью оптимизации многократного использования команды не имеет смысла

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

Многократно выполняемые SQL-запросы, как правило, содержат параметры, представляющие собой переменные в тексте SQL-запроса. IBProvider поддерживает два вида параметров: именованные и неименованные. Перед выполнением параметризованного SQL-запроса команда должна обладать описаниями параметров. Описание параметра — это его тип, имя, направление передачи значения (in-out). Пользователь может самостоятельно сформировать описания параметров или поручить формирование параметров команде.

Явное определение параметров SQL-запроса, несмотря на свою громоздкость при работе через ADODB. обеспечивает более эффективную работу с приложениями, поскольку исключается лишнее обращение к серверу для получения их описаний.

Пример явного определения параметров SQL-запроса:

ADODB

cmd.CommandText="select * from job where job_code=?"

cmd.Parameters.Append cmd.CreateParameter(,adBSTR,adParamlnput)

cmd(0)="Eng"

C++

t_db_row row;

t_db_row param(1);

_THROW_OLEDB_FAILED(cmd2,

prepare("select * from job where job_code=?",&row))

//тип параметра определяется его значением

param[0]="Eng";

param.count=1;

_THROW_OLEDB_FAILED(cmd2,execute(&param));

//Тип параметра задается отдельно от значения,

//в этом случае провайдер выполнит преобразование значения

//в указанный тип.

set_param(param,0,adBSTR,"Eng");

param.count=1;

_THROW_OLEDB_FAILED(cmd2,execute(&param));

Автоматическое определение описаний параметров SQL-запроса позволяет клиентскому приложению перепоручить отслеживание типов параметров InterBase и конвертору типов IB Provider.

Пример явного указания команде сгенерировать описания типов:

ADODB

cmd.CommandText = "select * from job where job_code=?"

cmd.Parameters.Refresh

cmd(0) = "Eng"

Явное указание обновления списка параметров (cmd.Parameters.Refresh) обычно можно опустить. Однако иногда это необходимо. Например, для выполнения такого цикла:

ADODB

Dim cmd As New ADODB.Command

Dim is As ADODB.Recordset

cmd.ActiveConnection = сn

cmd.CommandText = "select * from job where job_code=?"

Dirr i AS_ Long For i = 0 To 10

cmd.Parameters.Refresh

cmd(0) = "Eng"

Set rs = cmd,Execute

'...

'rs.Close

Next i

Вся хитрость заключается в том, что ADODB при выполнении второй итерации будет создавать новую OLE DB-команду, поскольку предыдущая занята обслуживанием результирующего множества SQL-запроса, созданного на первом шаге. Без строки cmd.Parameters.Refresh внутренний список описания параметров новой команды не будет сформирован, хотя коллекция ADODB.Command.Parameters будет содержать элементы. В результате при вызове метода cmd.execute в команду передаются значения параметров, описание которых у нее отсутствует. Принудительное обновление решает эту проблему. Понятно, что создание новой команды снижает производительность описанного выше алгоритма. Поэтому для того, чтобы ADODB могло повторно воспользоваться OLE DB-командой, нужно закрывать результирующее множество (rs.Close).

Повторный вызов cmd.Parameters.Refresh для одного и того же запроса не приводит к повторному обращению к серверу, поэтому расходы на такое дублирование ничтожны.

Автоматическая генерация описания параметров:

C++

_THROW_OLEDB_FAILED(cmd2,describe_params(param));

param[0]="Eng";

_THROW_OLEDB_FAILED(cmd2,execute(&param) ) ;

Существует единственное исключение, когда IBProvider обязательно выполнит дополнительный запрос на сервер для получения описания параметров SQL- запроса. Это касается слуиая, когда в параметре передается массив. Для такого типа параметров необходима дополнительная информация об имени таблицы и поля, в которые будут производить запись данных, а также информация о размерности массива. Подробности см. далее в разделе "Работа с массивами".

В вышеприведенных примерах были использованы неименованные параметры, обозначаемые в тексте запроса символом вопросительного знака. Именно такое обозначение параметров поддерживает и сам InterBase. Однако иногда удобно использовать именованные параметры в SQL-запросах:

* Именованный параметр можно многократно указывать в разных частях одного запроса.

* Порядок описания параметров может не соответствовать порядку использования параметров в тексте запроса. Это недопустимо для неименованных параметров.

В ADODB за удобство именованных параметров приходиться "платить" использованием режима автоматической генерации описания параметров (ADODB.Command.Parameters.Refresh). Причина заключается в том, что имя параметра, указываемое в ADODB.Command.CreateParameter, не передается команде. При использовании классов C++ такого ограничения нет - описание параметров можно формировать обоими способами. Еще одним ограничением, ADODB является невозможность использования именованных параметров для BLOB-полей -только неименованные параметры '?'.