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

Востриков С М

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-полей -только неименованные параметры '?'.

Как уже было сказано выше, команда запрещает одновременное использование в тексте запроса именованных и неименованных параметров.

Сам InterBase поддерживает неименованные параметры. Поэтому команда вынуждена заменять в тексте

запроса именованные параметры на неименованные параметры. Окончательный текст запроса, используемый для передачи на сервер, доступен через свойство команды "Prepare Stmt"

Пример многократного выполнения параметризованного запроса, содержащего именованный параметр:

ADODB

Dim cmd As New ADODB.Command

Dim rs As ADODB.Recordset

cmd.ActiveConnection = en

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

Dim i As Long

For i = 0 To 10

cmd.Parameters.Refresh

cmd("job_code") = "Eng"

Debug.Print cmd.Properties("prepare stmt")

Set rs = cmd.Execute

'...

rs.Close

Next i

Установка свойств результирующего множества

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

Пример настройки свойств набора результирующего множества команды:

ADODB

'разрешить поддержку закладок для

'произвольного позиционирования в наборе

cmd.Properties("Use bookmarks") = True

'Использовать 1 MB памяти для кеширования рядов

cmd.Properties("Memory Usage") = 1024

C++

t_db_obj_props cmd_props(false);

_THROW_OLEDB_FAILED(cmd_props,

attach_command(cmd2.command_obj));

_THROW_OLEDB_FAILED(cmd_props,set("Use Bookmarks",true));

_THROW_OLEDB_FAILED(cmd_props,set("Memory Usage",1024));

Выполнение команды

Вызов операции execute является последним этапом выполнения SQL-запроса к базе данных, в ко юром )частв)е] объект команды Первоначальное и почти полное описание всех этапов выполнения этой операции заняло больше двух листов, забитых сухой технической информацией, дочитывая которую забываешь, с чего все началось. Шутка. Поэтому ограничимся коротким списком задач, выполняемых командой при вызове операции выполнения SQL-запроса.

* Проверка параметров. Количество разнообразных ошибок, вылавливаемых на этом этапе, превышает полтора десятка.

* Получение транзакции, в рамках которой будет выполняться SQL-запрос. Это может быть собственная активная транзакция родительской сессии или отдельная автоматически завершаемая транзакция (если таковые разрешены).

* Создание нового дескриптора низкоуровневого запроса, если текущий, принадлежащий команде, обслуживает набор строк, сформированных предыдущим вызовом операции execute. Такая ситуация может произойти при многократных вызовах execute для одного и того же SQL-запроса.

* Подготовка команды, если эта операция еще не была выполнена.