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

Set rs = cmd.Execute

Dim col As Long

While Not rs.EOF

Debug.Print "----------------"

For col = 0 To rs.Fields.Count - 1

Debug.Print CStr(col) & ":" & rs.Fields(col).Name & " - " &

my_cstr(rs(col})

Next col

rs.MoveNext

Wend

cn.CommitTrans

End Sub

Вызов исполняемой ХП отличается от использования селективной ХП в том плане, что применяют SQL-запрос EXECUTE PROCEDURE... и получают результат работы через out-параметры. IBProvider различает только вызов исполняемой ХП, анализируя сигнатуру SQL-запроса. Наряду с SQL-выражением EXECUTE PROCEDURE..., непосредственно поддерживаемого InterBase, в тексте команды можно указывать EXECUTE ... и ЕХЕС ... IBProvider распознает в этих командах попытку вызова исполняемой ХП и автоматически приводит текст SQL-запроса к совместимому с InterBase. Для получения результата работы исполняемой ХП нужно либо самостоятельно описать out-параметры, либо попросить команду сформировать эти описания самостоятельно (ADODB Command Paiameters.Refresh). Основными правилами здесь являются:

* В тексте запроса out-параметры не упоминаются

* Описание out-параметров после in-параметров.

* Не обязательно определять все out-параметры. При работе через ADODB. это могут быть первые out-параметры из всего списка (пропуски не допускаются). При прямой работе с OLE DB-командой можно указывать имена интересующих выходящих параметров ХП, тем самым получать out-параметры в любой комбинации.

Тестовая база данных employee.gdb не содержит готовых примеров исполняемых ХП, поэтому для следующего примера будет определена своя собственная простейшая хранимая процедура.

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

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 обращений к серверу:

* Создание

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

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

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

* Разрушение

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

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

Ниже приводиться пример СОМ-объекта, который подключается к сессии и используется для того, чтобы получить значение генератора (см. главу "Таблицы Первичные ключи и генераторы" (ч. 1)). Здесь мы ограничимся лишь IDL-описанием двух интерфейсов и реализацией их методов. Помимо этого, используются возможности инструментальной библиотеки из дистрибутива IBProvider I.6.2. В реальном случае этот код, конечно же, лучше оформить в виде обычного класса. Тогда можно исключить одновременную поддержку ADODB и OLEDB. Кроме того, в данном примере не оптимизирована работа метода GenID для случая повторного использования подготовленной команды, для случая многократного вызова метода с идентичными аргументами.

IDL-описание интерфейсов:

////////////////////////////////////////////////////////////

//interface IDBSessionObject

// уcтановка/получение рабочей OLEDB-сессии объекта

[

object,

uuid(98E5AB40-333E-llD6-AC8F-OOAOC907DB93),

pointer_default(unique)

]

interface IDBSessionObject:IUnknown

{

HRESULT SetDBSession([in] lUnknown* pSession);

HRESULT GetDBSession([out]lUnknown** ppSession);

};//interface IDBSessionObject

/////////////////////////////////////////////

//interface IDBGenID

// интерфейс получения значения генератора

[

object,

uuid(98E5AB41-333E-llD6-AC8F-OOAOC907DB93),

dual,

oleautomation,

pointer_default(unique),

nonextensible

]

interface IDBGenID:IDispatch

{

[propput]

HRESULT Connection([in]IDispatch* pConnection);

[propget]

HRESULT Connection([out,retval]IDispatch** ppConnection);

HRESULT Convert([in]BSTR GenName,

[in]LONG Count,

[out,retval]LONG* pResult);

};//interface IDBGenID

Реализация методов установки сессии:

//m_spADODBConnection - член класса,

// содержащий указатель на ADODB-подключение

//m_spSession - член класса,

// содержащий указатель на используемую OLEDB-сессию

//m_Cmd - команда (t_db_command) получения значения генератора

//IDBSessionObject interface ------------------------------

HRESULT _stdcall TDBGenID::SetDBSession(lUnknown* pSession)

{

::SetErrorlnfo(0,NULL);

HRESULT hr=S_OK;

_OLE_TRY_

{

//освобождаем ADODB connection

m_spADODBConnection.Release();

m_spSession=pSession;

//инициализируем объекты взаимодействия с базой данных

m_Cmd destroy();

}

_OLE_DIS P_CATCHES_

return hr;

}//SetDBSession

HRESULT _stdcall TDBGenID::GetDBSession(lUnknown** ppSession)

{

::SetErrorlnfo(0,NULL);

return m_spSession.CopyTo(ppSession);

}//GetDBSession

//IOC2_ObjectLoader interface -----------

HRESULT _stdcall TDBGenID::put_Connection

(IDispatch* pConnection)

{

::SetErrorInf0(0,NULL);

HRESULT hr=NOERROR;

_OLE_TRY_

{

IDispatchPtr spConnection(pConnection) ; //блокируем в памяти