Определение исполнимой хранимой процедуры:

SQL

create procedure sp_calculate_values(x integer,у integer)

returns(valuel integer,value2 varchar(64))

as

begin

valuel=x+y;

value2=x-y;

end

Вызов и обработка результатов исполнимой хранимой процедуры SP_CALCULATE_VALUES:

ADODB

Sub sproc_exec

Dim en As New ADODB.Connection

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

cn.BeginTrans

Dim cmd As New ADODB.Command

cmd.ActiveConnection = cn

'автоматическое определение параметров

cmd.CommandText = "exec sp_calculate_values(:xl,:x2)"

cmd('x1") =200

cmd("x2") = 100

cmd.Execute

Debug.Print "outl=" & CStr(cmd("valuel"))

Debug.Print "out2=" & CStr(cmd("value2"))

' явное определение параметров

cmd.CommandText = "execute sp_calculate_values(?,?)"

cmd.Parameters.Append cmd.CreateParameter(, adlnteger,

adParamlnput, , 200)

cmd.Parameters.Append cmd.CreateParameter(, adlnteger,

adParamlnput, , 300)

cmd.Parameters.Append cmd.CreateParameter("vl", adlnteger,

adParamOutput)

cmd.Parameters.Append cmd.CreateParameter("v2", adBSTR,

adParamOutput)

cmd.Execute

Debug.Print "vl=" & CStr(cmd("vl"))

Debug.Print "v2=" & CStr(cmd("v2"))

сn.CommitTrans

End Sub

При явном определении параметров можно попробовать испытать мрован к'р на "прочность", задав некорректный порядок перечисления параметров. Например, сначала out-параметры, потом in-параметры.

Самым эффективным применением технологии OLEDB является создание и использование специализированных компонентов для работы с базой данных. Этот подход изначально начал применяться для серверов приложений (application servers). Однако ничто не мешает реализовывать re же самые принципы при создании обычного приложения базы данных. В этом случае, помимо обычных преимуществ компонентной технологии, исчезают типичные проблемы, связанные с передачей и разделением ресурсов сервера баз данных между несколькими модулями клиентского приложения. Для малосвязанных модулей достаточно разделять одно подключение, в случае использования сервисных компонентов может потребоваться совместная работа в контексте одной транзакции. Поскольку эти ресурсы представлены в виде СОМ-объектов, то для корректной работы требуется только правильно управлять их счетчиком ссылок. Однако для опытного программиста, использующего СОМ-технологии в реальной работе, это не проблема.

Исходя из накопленного опыта создания таких компонентов и их использования из программ, написанных на C++, VBA и VBScript, можно порекомендовать следующую структуру СОМ-объектов:

* Дуальный (dual) интерфейс автоматизации, через который выполняется основное взаимодействие с объектом. Этот же интерфейс предоставляет свойство Connection для того, чтобы устанавливать и получать подключение, используя ADODB-компоненты. Как уже было сказано ранее, ADODB.Connection одновременно является и источником данных и сессией.

* Обычный интерфейс (наследующий ILJnknown) для инициализации компонента посредством указателя на ITJnknown сессии.

* Внутренняя работа с базой данных осуществляется через низкоуровневые интерфейсы OLEDB посредством классов C++. Таким образом, компонент изолируется от ADODB и обеспечивает более производительное функционирование собственных алгоритмов.

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

В качестве поддержки совместного использования ADODB и OLEDB в одном проекте инструментальная библиотека представляет две утилиты:

* construct_adodb_connection - создание ADODB подключения на базе существующего источника данных и сессии;

* get_adodb_session - получение OLEDB-сессии, обслуживаемой ADODB-подключением.

Несмотря на открывающиеся в связи с использованием IBProvider перспективы, связанные с дроблением ваших приложений для InterBase на модули, главное не переусердствовать. Не стоит делать компоненты, предназначенные для коллекций, с собственным механизмом чтения и записи. Помните, что любой использующий команды объект делает как минимум 4-5 обращений к серверу:

* Создание

* Подготовка.

* Выполнение.

* Выборка результата.

* Разрушение

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

Еще одной хорошей идеей является создание в приложении обычных классов с реализацией той логики, которая скорее всего не потребуется вне границ вашего приложения. Согласитесь, что написание класса и СОМ-компонента требует несравнимых усилий. Кроме того, не забывайте, что создание СОМ-объектов производиться через СОМ-инфраструктуру, поэтому накладные расходы распространяются и на время выполнения приложения. Поэтому обычные классы все равно остаются основным "тактическим средством" больших приложений, разработанных в объектно-ориентированном стиле