26. Механизм прямого доступа к данным в клиентском приложении Delphi

Механизмы доступа к данным в среде Delphi

Средство быстрой разработки приложений Delphi использует универсальный механизм доступа к данным, реализованный в виде библиотек и дополнительных модулей, называемых драйверами или провайдерами. Библиотеки содержат стандартный набор функций и классов, которые подчиняются определенной спецификации. Дополнительные модули, специфичные для той или иной СУБД, реализуют непосредственное обращение к функциям клиентских API конкретных СУБД.

Достоинством универсальных механизмов является возможность применения одного и того же абстрактного API, для доступа к разным типам СУБД. Поэтому приложения, использующие универсальные механизмы доступа к данным, легко модифицировать, если необходима смена СУБД. При этом нередко модификация затрагивает не код приложения, а настройки доступа к данным, содержащиеся в реестре или внешних файлах. Однако за подобную универсальность приходится платить невозможностью доступа к уникальной функциональности, специфичной для конкретной СУБД, снижением производительности приложений и усложнением процедуры поставки приложения – ведь в его состав нужно включать библиотеки, ответственные за реализацию универсальных механизмов, драйверы для тех или иных СУБД, а также обеспечивать настройки, необходимые для их правильного функционирования.

Наиболее популярными среди универсальных механизмов доступа к данным являются:

Open Database Connectivity (ODBC).

OLE DB.

ActiveX Data Objects (ADO).

Borland Database Engine (BDE).

Все вышеперечисленные механизмы доступа, так или иначе, поддерживаются в Delphi.

Универсальные механизмы ODBC, OLE DB и ADO фирмы Microsoft представляют собой по существу промышленные стандарты. Механизм доступа BDE фирмы Borland, так и не стал промышленным стандартом, но достаточно широко используется разработчиками и поддерживается в Delphi на уровне компонентов и классов.

ODBC

ODBC (Open Database Connectivity) — широко распространенный программный интерфейс фирмы Microsoft, удовлетворяющий стандартам ANSI и ISO для интерфейсов обращений к базам данных CLI (Call Level Interface).

Для доступа к данным конкретной СУБД с помощью ODBC, кроме клиентской части этой СУБД, нужен ODBC Administrator (позволяющий создать и определить источники данных доступные на компьютере) и ODBC-драйвер для доступа к СУБД. ODBC-драйвер является динамической библиотекой (DLL), которую клиентское приложение может загрузить в свое адресное пространство и использовать для доступа к источнику данных. Для использования какой-либо СУБД необходимо использовать специальный ODBC-драйвер, предназначенный для конкретной СУБД.

С помощью ODBC можно манипулировать данными любой СУБД и даже данными, не имеющими прямого отношения к БД, если для них имеется ODBC-драйвер.

Спецификация ODBC подразумевает использование нескольких стандартов на ODBC-драйверы (обычно в этом случае употребляются термины Level 1, Level 2 и т.д.). Эти стандарты отличаются различной функциональностью, которая должна быть реализована в таком драйвере. Например, драйверы, соответствующие стандарту Level 1, не обязаны поддерживать работу с хранимыми процедурами, а некоторые ODBC-драйверы не поддерживают двухфазное завершение транзакций (применяемое в том случае, когда требуется согласованное изменение данных в нескольких различных серверных СУБД).

OLE DB и ADO

OLE DB и ADO – часть универсального механизма доступа к данным Microsoft (Microsoft Universal Data Access), позволяющая осуществить доступ, как к реляционным, так и к нереляционным источникам данных, таким как файловая система, данные электронной почты, многомерные хранилища данных и др.

Microsoft ActiveX Data Objects (ADO) – это набор библиотек, содержащих COM-объекты, реализующие прикладной программный интерфейс для доступа к таким данным и используемые в клиентских приложениях. ADO использует библиотеки OLE DB, предоставляющие низкоуровневый интерфейс для доступа к данным. OLE DB предоставляет доступ к данным с помощью COM-интерфейсов. Можно также использовать OLE DB непосредственно, минуя ADO.

Для доступа к источнику данных с помощью OLE DB требуется, чтобы на компьютере, где используется клиентское приложение, был установлен OLE DB-провайдер для данной СУБД. OLE DB-провайдер представляет собой DLL-библиотеку. Для каждого типа СУБД нужен собственный OLE DB-провайдер, так как эти провайдеры базируются на функциях клиентских API, разных для различных СУБД.

Среди OLE DB-провайдеров для разных источников данных имеется специальный провайдер Microsoft OLE DB Provider for ODBC Drivers. Этот провайдер использует не API клиентской части какой-либо СУБД, а интерфейс ODBC API, поэтому он применяется вместе с ODBC-драйвером для выбранной СУБД.

Отметим, что ADO становится все более популярным способом доступа к данным, так как входит в состав таких широко используемых продуктов, как Microsoft Office 2000 и Microsoft Internet Explorer 5.0, а также включен в ядро операционных систем семейства Windows.

BDE

BDE (Borland Database Engine) – универсальный механизм доступа к данным, применяемый в средствах разработки фирмы Borland (а именно – Delphi и C++Builder), а также в некоторых других продуктах, например Corel Paradox, Corel Quattro Pro, Seagate Software Crystal Reports..

BDE – это наследник библиотеки Paradox Engine, созданной для Borland Pascal и Borland C++ для доступа к таблицам СУБД Paradox. Вскоре после создания Paradox Engine компанией Borland было разработано несколько библиотек-драйверов под общим названием SQL Links. Эти библиотеки расширили функциональность BDE и позволили реализовать доступ к данным dBase, ODBC-источникам, а также наиболее популярным серверным СУБД. Позже к этому набору были добавлены библиотеки для доступа к Access и FoxPro.

Механизм BDE представляет собой программную прослойку между прикладной программой и БД. Запрос из приложения передается прослойке BDE, который использует драйверы для непосредственной работы с соответствующей БД. Физически BDE представляет собой набор библиотек доступа к данным, реализующих BDE API – набор функций для манипуляции данными, вызываемых из приложения. Эти функции, в свою очередь, могут обращаться к функциям клиентского API (в случае, например, Oracle, Informix, IB Database) или ODBC API (Access 2000, Microsoft SQL Server 7.0, любые ODBC-источники), а также непосредственно манипулировать файлами некоторых СУБД (dBase, Paradox).

Для доступа к БД с помощью BDE на компьютере, содержащем клиентское приложение, должны быть установлены библиотеки BDE общего назначения, а также BDE-драйвер для данной СУБД. В случае серверных СУБД такие драйверы носят название SQL Links. Эти драйверы содержат BDE API – стандартный набор функций, созданных на основе функций клиентских API соответствующих СУБД.

Среди BDE-драйверов имеется драйвер, созданный с использованием ODBC API, – так называемый ODBC Link, который применяется вместе с ODBC-драйвером для выбранной СУБД.

В отличие от ODBC-драйверов и OLE DB-провайдеров, выпускаемых как производителями СУБД, так и многими сторонними производителями, BDE-драйверы производятся только самой компанией Inprise.

27 Технология изменения данных с использованием компонента IBQuery: свойства, методы и события.

Компонент Query.

До текущего момента мы рассматривали язык SQL как таковой, оставляя вопросы его взаимодействия с Delphi. Переходя к практическим вопросам использования этого языка в приложениях, рассмотрим компонент Query. Компонент Query представляет собой компонент набора данных, записи которого формируются в результате выполнения SQL-запроса. При этом текст запроса также содержится в этом компоненте в виде свойства SQL типа TStrings.

В целом, с точки зрения использования в приложении, компонент Query похож на другой компонент BDE - Table. Подобно Table, он так же может выступать в качестве источника данных. Однако благодаря тому, что практически все параметры, относящиеся к выборке данных, определяются в тексте запроса, то среди свойств этого компонента, связывающих его с БД, имеется лишь DatabaseName.

Еще одним важным отличием компонента Query от Table является отсутствие у Query свойства ReadOnly. Дело в том, что компонент Query по своей сути обычно предоставляет данные, доступные только для чтения, т.е. связь получается односторонняя. Этот факт следует учитывать, т.к. в ряде случаев при установке взаимодействий между компонентами бывает необходимым ссылаться на источники данных, поддерживающих непосредственную правку. В то же время, если выполняется ряд определенных условий, в частности, запрос обращается только к одной таблице, сама таблица поддерживает запись, а свойство RecuestLive компонента Query установлено в истину, то к такому запросу можно будет обращаться точно так же, как к таблице.

В то же время, подобные ограничение вовсе не говорит о том, что при помощи Query сложно изменять данные - просто для этих целей понадобится создавать соответствующий SQL-запрос (например, с командой UPDATE), а не пытаться использовать свойства объектов Filed. Кроме того, к Query неприменимы такие методы, как FindFirst, FindLast и т.д.

В качестве примера простейшего приложения, использующего этот компонент, рассмотрим уже упоминавшийся SQL Explorer LE. В каталоге Tools\SQLE_LE, помимо самого приложения, находится его исходный код. Не вдаваясь в подробности реализации, отметим лишь, что в приложении задействовано 3 компонента, связанных с доступом к данным - это Database, Query и DataSource. Еще один невизуальный компонент - диалог открытия файла используется для выбора каталога с БД. Весь написанный код этого приложения приведен в листинге 21.1.

Листинг 21.1. Исходный код SQLE LE

procedure TMainFrm.OpenBtnClick(Sender: TObject); begin if not OpenDlg.Execute then exit; MainDB.Connected:=false; MainDB.Params.Clear; MainDB.Params.Add('path='+ExtractFilePath(OpenDlg.FileName)); MainDB.Connected:=true; RunBtn.Enabled:=true; end; procedure TMainFrm.RunBtnClick(Sender: TObject); begin Query1.Close; Query1.SQL.Text:=Memo1.Text; if pos('select',lowercase(Memo1.Text))=0 then Query1.ExecSQL else Query1.Open; end;

Здесь кнопка открытия БД устанавливает путь к базе данных (подразумевается, что используется СУБД Paradox), после чего делает соединение активным, а кнопку выполнения запроса - доступной. Код для кнопки выполнения запроса нуждается в некотором пояснении: дело в том, что у компонента Query имеется 2 способа выполнения запроса - при помощи методов Open и ExecSQL. Принципиальная разница между ними состоит в том, что метод Open используется для запросов, производящих выборку данных (т.е. SELECT), в остальных же случаях предпочтительнее использовать метод ExecSQL.

Компонент Query имеет большинство свойств и методов, совпадающих с Table. Дополнительное преимущество Query – возможность формировать запросы на языке SQL. Если запрос SQL сводится к просмотру таблицы (запрос Select), то результат этого запроса (а не сама исходная таблица) помещается во временном файле на компьютере пользователя. Это таблица только для чтения и не допускает каких-либо изменений. Если же запрос связан с какими-либо изменениями содержания таблицы, то никаких временных таблиц не создается. BDE передает запрос на сервер, там он обрабатывается и в приложение возвращается информация о том, успешно ли завершена соответствующая операция. Таким образом, эффективность Query при работе в сети выше, чем у Table. Компонент Query (набор данных) помещается на форму вместе с компонентом DataSource(источник данных) и компонентами отображения данных, например, DBGrid. Основное свойство компонента Query – SQL, имеющее тип TString. Это список строк, содержащих запросы SQL. В процессе проектирования приложения необходимо сформировать в этом свойстве некоторый предварительный запрос SQL, который показал бы, с какой таблицей или таблицами будет проводится работа. Но далее во время выполнения приложения свойство SQL может формироваться программными методами, обычными для класса TString: Clear – очистка, Add – добавление строки и т.д. Свойство DataBaseName компонента Query служит для задания базы данных, с которой осуществляется связь путем выбора из выпадающего списка псевдонимов или указанием полного пути к файлу. Свойства TableName у компонента Query нет, так как таблица, с которой ведется работа, будет указываться в запросах SQL. Поэтому в свойство SQL надо занести запрос, содержащий таблицы и перечисляются параметры, если они используются в приложении. Пока такой запрос в SQL отсутствует, дальнейшая настройка Query невозможна. Если запрос, введенный в SQL , имеет вид

Select * from pers при задании свойства Active=true можно сразу в процессе проектирования увидеть результаты работы этого запроса. Если работа проводится с несколькими таблицами: Select * from pers,dep Для управления отображением данных в компоненте Query, как и в компоненте Table имеется редактор полей Field Editor. Он вызывается либо двойным щелчком на компоненте Query, либо из контекстного меню и выбором пункта Fields Editor. В нем можно добавить имена получаемых полей (add), задать заголовки полей, отличающиеся от их имен, сделать поля невидимыми (visible), нередактируемыми (ReadOnly), в логических полях задать текст(например: да;нем, м;ж)., задать формат высвечивания чисел, создать вычисляемые поля, задать диапазоны значений и др.