Что такое FIBPIus?
Предыдущие главы книги содержали описание самого сервера InterBase, но для практического его использования необходимо разрабатывать клиентские программы. Само название технологии Client/Server говорит о наличие двух сторон: сервера, который в нашем случае обслуживает базу данных, и клиента, который является специализированной программой, взаимодействующей с сервером InterBase.
Для написания клиента, или клиентской части, вы в принципе можете использовать практически любые среды разработки, которые позволяют вызывать функции из внешней DLL-библиотеки. Суть взаимодействия с InterBase состоит в том, что ваша программа вызывает некоторые функции InterBase API для выполнения тех или иных запросов к базе данных. InterBase API заключено в специальной библиотеке gds32.dll. Таким образом, вы имеете возможность писать свои программы на чем угодно, обращаясь к функциям gds32.dll. Тем не менее, такой низкоуровневый подход неудобен для создания прикладных программ, в которых основное внимание уделяется обработке данных на достаточно абстрактном уровне. Если разработчик вынужден каждый раз заботиться, прежде всего, о том, чтобы правильно сформировать внутренние структуры для вызова функций gds32.dll, то процесс разработки значительно усложняется и затягивается.
Этого можно избежать, если вы используете для разработки клиентской части Borland Delphi, Borland C++ Builder или Borland Kylix. Идеология этих продуктов поощряет создание специализированных наборов компонент для решения определенных системных задач, облегчая, таким образом, жизнь прикладного разработчика.
Devrace FIBPIus - это библиотека компонент для Delphi, C++ Builder и Kylix, предназначенных для работы с InterBase и его клонами (Firebird и Yaffil). Компоненты используют прямой InterBase API для взаимодействия с сервером, поэтому для нормальной работы программ, написанных с использованием FIBPIus, не нужно ничего, кроме наличия gds32.dll. Кроме того, использование прямого API дает клиентским приложениям максимальную производительность, гибкость и возможность использования "специальных" уникальных вещей, реализованных в InterBase. В частности, можно упомянуть array-поля, которые невозможно использовать при работе со стандартными Delphi компонентами ТТаЫе, TQuery, взаимодействующими с InterBase через Borland Database Engine (BDE).
Попробуем кратко перечислить основные возможности и преимущества FIBPIus:
Полная совместимость со Borland Delphi 3-7, C++ Builder 3-6 и Kylix 3.
Полная совместимость с существующими версиями InterBase 4.X-7.0, Firebird, Yaffil в настоящий момент, а также поддержка всех версий InterBase и его основных клонов в будущем.
Поддержка всех особенностей и специальных возможностей InterBase: event alerters, array-полей, blob-полей.
Встроенные макросы в SQL-выражениях, позволяющие использовать параметры-подстановки даже в там, где это не позволяет сам InterBase.
Удивительно гибкий механизм работы с master-detail запросами, позволяющий свести "ручное" кодирование практически к нулю и при этом иметь возможность гибко настраивать любые связки master-detail без написания обработчиков событий, улучшая общую производительность приложения за счет снижения лишнего сетевого трафика.
Улучшенная производительность при выполнении запросов со средним и небольшим количеством результирующих записей (т. е , для 90-95% всех запросов в обычных приложениях!).
Гибкое управление транзакциями. FIBPlus, которое позволяет, с одной стороны, явно управлять каждой транзакцией, а с другой стороны автоматизирует большинство операций, автоматически запуская транзакции, и подтверждая их в режиме AutoCommit. Кроме этого, FIBPlus реализует уникальный механизм работы одного компонента в контексте двух транзакций: читающей и пишущей, что позволяет совершенно избегать DEADLOCK при работе приложения.
Реализация и поддержка дополнительных возможностей, например, эмуляция Boolean-полей, отсутствующих в явном виде в InterBase. Качественная поддержка режима CachedUpdates позволяет использовать FIBPlus в приложениях с нестабильными удаленными подключениями к базе данных (например, посредством dial-up). Используя CachedUpdates, вы можете подключиться к базе данных, выбрать данные, отключиться, изменить данные и после повторного подключения (или восстановления подключения), вернуть изменения на сервер. Данная возможность реализована только в FIBPlus, поскольку, например, в IBX даже при режиме CachedUpdates необходимо, тем не менее, иметь активные транзакции и подключение к серверу.
Поддержка локальной сортировки и локальной фильтрации данных (без дополнительных запросов на сервер).
Автоматическая генерация модифицирующих запросов в run-time и design- time. Уникальная возможность автоматически генерировать модифицирующие запросы, в которых участвуют не все поля записи, а только те, значения которых реально были изменены, что позволяет снизить сетевой траффик приложения.
Аккуратная поддержка auto-increment полей, не требующая переоткрытия запроса после вставки новой записи, чтобы получить значения полей, измененных триггерами.
Возможность централизованной обработки ошибок и исключений при помощи компонента TpFIBErrorHandler.
Уникальная возможность создания цепочек модифицирующих запросов при помощи компонента TpFIBUpdateObject. Компонент позволяет реализовывать без ручного кодирования выполнение нескольких автоматических модифицирующих действий. Причем, эти модифицирующие запросы автоматически получают параметры от TpFIBDataSet и могут работать в рамках разных транзакций и даже разных подключений к базам данных. Управляя только свойствами TpFIBUpdateObject, разработчик может активировать или деактивировать нужные ему цепочки запросов. Все это превращает TpFEBUpdateObject в некое подобие триггера, реализованного в клиентской части приложения.
Полная поддержка Services API, что позволяет включать в приложения функции удаленного администрирования баз данных и самого сервера.
Компоненты FffiPlus построены таким образом, чтобы их можно было использовать со всеми стандартными визуальными db-компонентами и сторонними продуктами, поддерживающими стандарт TDataSet-TDataSource. Таким образом, разработчик, выбравший FffiPlus для доступа к InterBase, не ограничен в выборе сторонних компонент для отображения данных, или печати отчетов (мы покажем, в частности, как использовать FffiPlus в связке с FastReport).
Для любознательного читателя, возможно, будет также интересно узнать некоторые факты из истории появления и развития FffiPlus. В 1998 году независимый разработчик Грегори Дилтц создал минимальный набор компонентов для работы с InterBase API, назвав его FreeffiComponents (FffiC). Уже с 1999 года одесский программист Сергей Бузаджи стал дописывать эту бесплатную библиотеку своими более функциональными компонентами, назвав эти дополнения FffiPlus. Тогда же корпорация Borland выпустила Delphi 5, включив в нее компоненты InterBase Express (ffiX), полностью основанные на коде FIBC. Сам Грегори Дилтц отказался от продолжения развития своей библиотеки. К этому времени изменения в FffiC, сделанные Сергеем Бузаджи, были столь значительны и затрагивали практически весь первоначальный код Грегори Дилтца, что было решено развивать FIBPIus как отдельный проект, в рамках условий лицензионного соглашения Грегори Дилтца. С этого времени поддержкой и развитием библиотеки занимается компания Devrace, Сергей Бузаджи является ведущим разработчиком и идеологическим руководителем данного продукта. На текущий момент библиотека полностью совместима с Borland Delphi 3-7, Borland C++ Builder 3-5, Borland Kylix 3 и поддерживает Borland InterBase 4-7.0, а также все версии Firebird и Yaffil.
FIBPIus является коммерческим продуктом, однако компания Devrace ввела специальную цену для стран бывшего Союза, которая в десятки раз меньше цены для "западных" пользователей.Вы можете найти всю информацию о FIBPIus на сайтах: http://www.devrace.com, http://www.fibplus.net.
Что такое InterBase Express?
Пользователи Borland Delphi 5-7 и Borland C++ Builder 5-6 редакций Professional и Enteiprise наверняка уже обратили внимание на закладку InterBase в палитре компонентов. Именно эта закладка и представляет собой набор компонент под общим названием InterBase Express или IBX. Это компоненты для работы с базами данных InterBase, которые используют прямое InterBase API, т. е. обращаются к серверу непосредственно, без каких-то промежуточных (middle-ware) средств.
Фактически если разрабатывать приложения баз данных с использованием IBX, то для работы таких приложений нужно лишь наличие GDS32.DLL на диске в доступном месте.
Официально разработка IBX ведется в рамках IPL - InterBase Public License, т. е. компоненты доступны в полных исходных текстах и вы можете использовать их совершенно бесплатно. Однако фактически данные компоненты разрабатываются только сотрудниками корпорации Borland, совместимы только с определенными версиями и редакциями Delphi и C++ Builder и недоступны для публичной разработки, как это принято в обычных Open Source-проектах.
Компоненты IBX позволяют разрабатывать приложения, ориентированные на идеологию и архитектуру InterBase. К особенностям IBX можно отнести:
явное управление транзакциями;
поддержке расширений InterBase 6.0-7.0;
поддержку event-alerters;
использование генераторов для значений ключевых полей;
управление сервером через Services API;
поддержку стандартных и сторонних визуальных компонентов отображения данных;
поддержку встроенных и сторонних генераторов отчета;
совместимость с Delphi 5-7, C++ Builder 5-6 и Kylix
Основой кода IBХ является библиотека FreelBComponents, написанная Грегори Дилтцом в 1998 году. Основные изменения, сделанные в Borland, касались поддержки нового стандарта идентификаторов в SQLDialect 3, а также приведение компонентов к виду, аналогичному существовавшим компонентам (мы поясним суть этой аналогии позднее). Теперь с выходом каждой очередной версии Delphi или C++ Builder IBX включается в поставку, однако все равно желательно проверять наличие исправлений или дополнительных сборок на сайте http://codecentral.borland.com.
И снова про транзакции
Новичков иногда пугает "особенность" IBX закрывать все запросы при подтверждении или "откате" транзакции. Разместим на нашей форме две кнопки, как показано на рис. 2.10: Button 1 (свойство Caption равно Commit) и Button2 (Rollback).
Рис 2.10. Кнопки управления транзакцией
Далее напишем следующие обработчики событий нажатия на эти кнопки:
procedure TForml.ButtonlClick(Sender: TObject);
begin
IBTransactionl.Commit;
end;
procedure TForml.Button2Click(Sender: TObject);
begin
IBTransactionl.Rollback;
end;
Теперь если мы запустим приложение и нажмем любую из этих кнопок, то увидим, что после завершения транзакции наш запрос также будет закрыт.
Это действие совершенно очевидно, поскольку, как уже было сказано, любой запрос должен выполнятся только в рамках определенной транзакции и, таким образом, если транзакция уже закрыта, то запрос не может быть активным.
Однако для тех разработчиков, которые до сих пор пользовались BDE, такое поведение компонентов непривычно. Существует два метода. Первый: запоминать активные записи во всех открытых запросах перед закрытием транзакции, потом заново открывать все запросы и перемещать указатели текущих записей на "старое место". Именно так и работает механизм неявного переоткрытия, реализованный в BDE. Второй - это использовать методы CommitRetaining и RollbackRetaining, впервые появившиеся в InterBase 5.x. Эти методы в целом аналогичны методам Commit и Rollback, однако они реализованы таким образом, что сервер автоматически перезапускает транзакцию и не закрывает открытых запросов. Использование CommitRetaining и RollbackRetaining позволит вам избегать массовых операций переоткрытия ваших запросов.
Однако тут есть одна особенность, которая сразу не бросается в глаза. Предположим, что вы делали какие-то изменения, после чего решили отменить их и вызвали RollbackRetaining. Все модифицирующие запросы, которые были отправлены на сервер в контексте данной транзакции, будут отменены, однако локальный буфер TIBDataSet останется неизмененным.
Таким образом, содержимое, например, TDBGrid в вашем приложении будет отличаться от реального состояния таблицы на сервере. Поэтому мы рекомендуем вам все-таки заново открывать запросы, изменения которых были отменены при помощи RollbackRetaining.
Иерархия компонентов в IBX
Поскольку вы работаете с Delphi (или с C++ Builder), то предполагается, что вы знакомы с объектно-ориентированным программированием Таким образом, разобравшись, как именно и от кого унаследованы различные компоненты IBX, можно будет более полно представить себе, как именно их нужно использовать. Рассмотрим рис. 2.1.
Рис 2.1. Иерархия компонентов IBX
Внимательно рассмотрев эту схему, можно сделать сразу несколько выводов.
Во-первых, очевидна несовместимость IBX с версиями Delphi меньше 5, поскольку класс TCustomConnection появился лишь в Delphi 5.
Во-вторых, становится ясно, почему компонент TIBSQL невозможно использовать вместе с визуальными db-aware-компонентами вроде TDBGrid или TDBEdit. Все стандартные визуальные db-aware-компоненты работают только с потомками класса TDataSet. Поэтому для db-aware компонентов невозможна связка с TIBSQL, который не унаследован от TDataSet.
Из той же схемы видно, что в IBX есть компоненты, совместимые с db-aware-компонентами (TDBGrid и т. д.). Это потомки внутреннего класса TIBCustomDataSet - TIBDataSet, TIBTable, TIBQuery и TIBStoredProc Вообще говоря, почти вся данная "ветка" классов по своему назначению близка к аналогичной ветке компонентов для работы с BDE - TTable, TQuery и TstoredProc - и предназначена для "быстрой" миграции старых приложений с BDE на IBX.
Также следует обратить внимание на компонент TIBUpdateSQL, который является аналогом компонента TUpdateSQL, предназначенного для работы с BDE
Судя по отзывам пользователей, переходящих с BDE на IBX, в действительности такое сопоставление компонентов IBX и BDE не всегда приносит желаемый результат, так как взаимозаменяемость старых BDE-компонентов на новые аналоги из IBX зачастую противоречит рекомендациям специалистов в силу различий в идеологии
Прежде всего это связано с управлением транзакциями и обработкой большого котичества записей Ниже мы остановимся на этом вопросе подробнее, а теперь перейдем к рассмотрению особенностей компонентов TIBTable, TIBQuery и TIBStoredProc
Использование FIBPIus совместно с генератором отчетов FastReport
Фактически компоненты FIBPIus совместимы с любыми генераторами отчетов, которые работают с потомками стандартного класса TDataSet. Таким образом, вы сможете использовать FIBPIus вместе с QuickReport, ReportBuilder, FastReport и даже со специализированными генераторами отчетов, такими, как, например, Afalina XLReport.
Все эти генераторы будут получать данные из TpFIBDataSet напрямую или через компонент TDataSource. Мы не будем останавливаться на рассмотрении всех особенностей всех генераторов, а просто продемонстрируем как быстро и просто можно получить отчет при помощи FastReport от FastReport Software. Отметим, что, как и FIBPIus, этот генератор отчетов можно использовать не только при разработке приложений в Borland® Delphi® для Microsoft® Windows®, но и в Borland® Kylix® для Linux®. Для этого предназначена специальная CLX-версия пакета.
Использование генераторов для автоинкрементных полей
Чаще всего автоинкрементные поля используются для поддержки суррогатных первичных ключей. В таблице заводится поле, значения для которого генерируются при помощи доступных технических средств, гарантирующих уникальность получаемых значений.
Существует несколько способов получения таких значений, мы же остановимся на том, который рекомендуется для большинства баз данных в InterBase. Как вы знаете, в InterBase существуют специальные объекты - генераторы, которые гарантируют получение уникальных возрастающих значений, независимых от контекста транзакций.
В IBDataSet существует специальное свойство, которое позволяет нам удобно использовать генераторы для создания уникальных значений первичного ключа, а именно GeneratorField. У этого свойства существует специальный редактор, доступный в design-time (рис. 2.11).
Рис 2.11. Настройка автоинкрементного поля
Укажите название генератора, имя поля в таблице, значения для которого будут генерироваться, шаг увеличения счетчика (в большинстве случаев это 1), а также опцию, указывающую, когда будет генерироваться значение поля: сразу при вставке новой записи (On New Record), при завершении вставки (On Post) или при помощи триггера (On Server). В последнем случае вы не увидите значения сгенерированного поля, пока не переоткроете весь запрос, однако данная опция все равно может оказаться полезной. Поскольку наше поле EMP_NO входит в первичный ключ, то его значение не может формально быть незаданным (NULL). Если не указывать свойство GeneratorField, то DBDataSetl будет требовать от нас указывать значение поля EMP_NO в обязательном порядке и мы не сможем "переложить ответственность" на триггер.
Указав же явным образом, что значение поля будет получено именно в триггере, мы обойдем это ограничение. Тем не менее мы рекомендуем вам использовать опции On New Record или On Post, поскольку они лучше укладываются в общую идеологию применения IBX.
Если мы получаем значение первичного ключа до отправки на сервер, то IBDataSetl сумеет корректно выполнить RefreshSQL. Если же мы будем использовать для генерации триггер, то IBDataSetl не сможет подставить правильное значение в RefreshSQL, поскольку значения полей в условии WHERE еще неизвестны.
Использование основных компонентов FIBPIus
В процессе более подробного рассмотрения вопросов использования компонентов FIBPIus мы постараемся создать очень простое приложение, которое будет предназначено для редактирования некоторого достаточно абстрактного прайс-листа. Этот пример позволит рассмотреть все основные аспекты работы с FIBPIus, с которыми так или иначе сталкивается практически каждый прикладной разработчик.
Наше приложение должно позволять редактировать категории товаров, список товаров для каждой категории и печатать прайс-лист. Нам понадобятся две таблицы: для категорий товаров и для списка товаров:
CREATE TABLE "Categories" (
"Id" INTEGER NOT NULL,
"Name" VARCHAR (50) character set WIN1251 collate PXW_CYRL,
"GoodsCount" INTEGER);
/* Unique keys definition */
ALTER TABLE "Categories" ADD CONSTRAINT "PK_Categories" PRIMARY
KEY ("Id");
SET TERM ^ ;
/* Trigger: "AI_Categories_Id" */
CREATE TRIGGER "AI_Categories_Id" FOR "Categories" ACTIVE
BEFORE INSERT POSITION 0
AS
BEGIN
IF (NEW."Id" IS NULL) THEN
NEW."Id" = GEN_ID("Categories_Id_GEN", 1);
END
^
SET TERM ; ^
CREATE TABLE "Goods" (
"Id" INTEGER NOT NULL,
"Name" VARCHAR (150) character set WIN1251 collate
PXW_CYRL,
"Price" DOUBLE PRECISION,
"IdCategory" INTEGER NOT NULL);
/* Unique keys definition */
ALTER TABLE "Goods" ADD CONSTRAINT "PK_Goods" PRIMARY KEY
("Id");
/* Foreign keys definition */
ALTER TABLE "Goods" ADD CONSTRAINT FK_GOODS FOREIGN KEY
("IdCategory") REFERENCES "Categories" ("Id") ON DELETE CASCADE
ON UPDATE CASCADE;
SET TERM ^ ;
/* Trigger: "AI_Goods_Id" */
CREATE TRIGGER "AI_Goods_Id" FOR "Goods" ACTIVE
BEFORE INSERT POSITION 0
AS
BEGIN
IF (NEW."Id" IS NULL) THEN
NEW."Id" = GEN_ID("Goods_Id_GEN", 1);
END
^
Очевидна связь master-detail между таблицами "Categories" и "Goods".
Обратите внимание, что мы с самого начала и в дальнейшем будем использовать особенности SQLDialect 3, который доступен в InterBase начиная с версии 6.0
Для печати прайс-листа мы будем использовать генератор отчетов FastReport f (http://www.fastreport.ru).
Использование основных компонентов InterBase eXpress (IBX)
Исторически сложилось так, что первое издание книги не содержало материалов по IBX. То есть данная глава написана специально для второго издания. После выхода книги мы получили ряд отзывов, которые наглядно показали нам, что многие разработчики (особенно те, кто впервые работает с ЮХ или FffiPlus) не представляют, как в целом взаимодействуют компоненты ЮХ между собой. В итоге, несмотря на аккуратное воспроизведение всех примеров из главы по FffiPlus, некоторые программисты не могут ни на шаг отойти от описанных ситуаций, поскольку спотыкаются буквально на совершенно очевидных вопросах. Чтобы осветить технологию несколько с других позиций, мы решили спланировать материал этой главы немного иначе, чем это было сделано с материалами по FffiPlus
Использование специальных инструментов в design-time: FIBPIus Tools
Кроме компонентов библиотека FIBPIus также включает ряд дополнительных инструментов - FIBPIus Tools, которые расширяют возможности среды разработки специально для более удобного и эффективного использования FIBPIus.
Использование стандартных визуальных db-компонентов совместно с FIBPIus
Следующий этап - получение данных из базы данных и отображение этих данных при помощи визуальных компонентов (рис. 2.17).
Рис 2.17. Подключение визуальных компонентов к TpFIBDataSet
Для этого нам необходимы два компонента. TpFIBDataSet HTpFTBTiansdction. TpFIBDataSet является потомком класса TDataSet и полностью совместим со всеми стандартными визуальными компонентами. Для связки TpFIBDataSet с визуальным компонентом CategoriesGrid (TDBGrid) компонент CategoriesDataSource подключен к CategoriesDataSet. TpFIBTransaction, как уже было сказано, предназначен для управления транзакцией.
Необходимо указать уровень изоляции транзакции при помощи свойства TPBMode, а также "подключить" CategoriesTransaction к pFIBDatabasel (2.18).
Рис 2.18. Подключение транзакции к компоненту pFIBDataBasel
Аналогично необходимо указать свойства Database и Transaction для компонента CategoriesDataSet (рис. 2.19).
Рис 2.19. Подключение компонента CategoriesDataSet к pFIBDataBasel и транзакции CategoriesTransaction
Теперь мы можем указать необходимые запросы к базе данных для получения и изменения данных в таблице Нужно написать запрос для получения данных, используя свойство SelectSQL. В нашем случае это будет очень простой запрос:
SELECT * FROM "Categories"
Теперь изменим немного код в процедуре:
procedure TMainForm.FormCreate(Sender: TObject);
begin
with TiniFile.Create('ib_price.ini') do begin
pFIBDatabasel.DBName := ReadString('Options', 'DBPath',
'C:\IBPRICE.GDB');
Free ;
end;
pFIBDatabasel.Open;
CategoriesDataSet.Open;
end;
В свойстве DataSet у компонента CategoriesSource (TDataSource) мы укажем CategoriesDataSet, а в свойстве DataSource у компонента CategoriesGrid (TDBGrid) укажем CategoriesSource. Теперь все данные, полученные в результате запроса, будут отображены в CategoriesGrid. Нам не нужно явным образом запускать транзакцию перед открытием запроса, поскольку по умолчанию свойство CategoriesDataSet.Options содержит ключ poStartTransaction и компонент сам запускает транзакцию После запуска приложения и открытия базы данных мы увидим следующий результат (рис. 2.20):
Рис 2.20. Вид запущенного приложения
Вместо CategoriesGrid мы могли использовать любой визуальный db-компонент, который используется в связке с TDataSource. Это мог быть TDBEdit, TDBLabel, TDBMemo и т. д., а также любые сторонние компоненты, которые придерживаются данного стандарта (TDBGridEh, например).
Эмуляция Boolean-полей
Вы уже знаете, что InterBase не поддерживает логического типа данных. Чем бы это ни было вызвано, нам остается только огорчиться этим фактом, поскольку на практике логический тип очень удобен. Разработчики, использующие InterBase, вынуждены заменять его другими типами, вводя ограничение на множество допустимых значений. Как правило, в базе данных создается соответствующий домен одного из двух видов.
CREATE DOMAIN TBOOLEAN_CHAR AS CHAR(1)
DEFAULT 'F' NOT NULL
CHECK (VALUE IN ('F', 'T'))
CREATE DOMAIN TBOOLEAN_INT AS INTEGER
DEFAULT 0 NOT NULL
CHECK (VALUE IN (0, 1))
При использовании любой библиотеки компонент для доступа к InterBase оба способа совершенно равноценны, поскольку для полей, созданных с такими доменами, в приложении все равно не создаются Boolean-поля. То есть если мы добавим некоторое логическое поле к нашей таблице:
ALTER TABLE "Categories" ADD IS_ACTIVE TBOOLEAN_INT
NOT NULL
А потом, используя, например, компоненты IBX, сделаем выборку при помощи компонента TIBDataSet:
SELECT "Categories"."Name", "Categories".IS_ACTIVE
FROM "Categories"
то в результате компонент создаст два внутренних компонента для полей:
TIBStringField для поля "Name" и TmtergerField для поля "IS_ACTIVE"
Последнее совершенно верно, поскольку формально поле "IS_ACTIVE" не является логическим. Таким образом, все визуальные компоненты типа TDBGnd и его расширенные аналоги от сторонних производителей не будут обрабатывать данное поле так, как нам бы хотелось. Например, если даже компонент умеет рисовать "галочки" для Boolean-полей, значения которых равно True, то поскольку он будет "видеть" всего лишь целочисленное поле, то и выводить он будет "0" и "1" Разумеется, если мы напишем соответствующие обработчики событий, то сможем добиться более или менее сносного отображения логических величин для поля TIntergerField, однако FIBPlus предоставляет гораздо более простое и качественное решение
Фактически оно состоит только в том, что нам необходимо добавить ключ poUseBooleanField в свойстве PrepareOptions (рис. 2.60).
Рис 2.60. Использование PrepareOptions для эмуляции Boolean—полей
После этого поля, созданные на основе целочисленного домена, в названии которого присутствует слово "boolean", будут считать логическими, и для них будут создаваться экземпляры TFIBBooleanField. Данный класс является прямым потомком класса TBooleanField и является полноценным логическим полем Любые визуальные компоненты для отображения данных будут работать с такими полями как с логическими, т. е. используя свойство AsBoolean. Вам же не придется писать для этого никакой дополнительный код.
Как сделать запрос редактируемым?
Если вы попробуете исправить какие-то значения в CategoriesGrid, то увидите, что в текущем состоянии мы имеем iead-only-запрос Для того чтобы наш запрос стал редактируемым, или "живым", нам надо написать несколько дополнительных запросов, которые будут автоматически выполнятся компонентом CategonesDataSet при редактировании данных в CategoriesGrid. Необходимо заполнить свойства (рис. 2.21).
Рис 2.21. Свойства CategonesDataSet с запросами для чтения и модификации данных
FIBPlus включает специальный design-time-редактор для редактирования и генерации модифицирующих запросов. Вы можете вызвать "Generator SQLs" из контекстного меню, если нажмете правой кнопкой мыши на компоненте CategonesDataSet (рис. 2.22)
Для генерации модифицирующих запросов необходимо сначала указать основную таблицу в списке Если в запросе участвует только одна таблица, то она будет выбрана в списке автоматически После этого необходимо нажать кнопку Get Table Fields для заполнения списков "Key Fields" и "Update Fields '. В первом списке нужно выделить те поля, которые будут вставлены в условие WHERE во всех модифицирующих запросах. В списке "Update Fields" необходимо выделить те поля, которые мы хотим редактировать. По умолчанию выделены все поля таблицы "Categories" Теперь достаточно нажать кнопку Generate SQLs и получить автоматически все модифицирующие запросы, которые вы можете увидеть на закладке SQLs Например, мы получим следующий запрос для свойства InsertSQL
INSERT INTO "Categories"(
"Id" ,
" Name" ,
"GoodsCount"
)
VALUES(
:"Id",
:"Name",
:"GoodsCount"
)
Puc 2.22. Редактор компонента TpFIBDataSet, предназначенный для генерации модифицирующих запросов
Обратите внимание также на запрос для свойства RefreshSQL:
select * from "Categories"
WHERE
(
"Categories"."Id" = :"OLD_Id"
)
Это такой же выбирающий запрос, как и запрос в свойстве SelectSQL, но возвращать он должен только одну запись - текущую Теперь, после создания всех запросов, когда пользователь будет редактировать запись в CategoriesGrid, CategonesDataSet автоматически заполнит значения параметров : "Id", . "Name" и т д., теми значениями полей, которые наберет пользователь. После выполнения метода Post (который, в частности, вызывается при нажатии клавиши Enter в CategonesGnd) CategoriesDataSet выполнит соответствующий модифицирующий запрос После редактирования записи будет выполнен запрос из свойства UpdateSQL, при вставке новой записи - из InsertSQL, а при удалении записи - из DeleteSQL После выполнения любого модифицирующего запроса (кроме удаления) CategoriesDataSet автоматически выполняет запрос из RefreshSQL, подставляя в качестве условия текущие значения параметров. Это позволяет "узнать" значения всех полей текущей записи, если они были изменены при помощи триггеров базы данных.
Несколько слов о специальных префиксах для параметров, которые используются в FIBPlus.
Префикс "OLD_" фактически означает текущее значение одноименного поля или же предыдущее значение поля Термин "предыдущее значение" имеет смысл в запросе на удаление. Во всех остальных случаях, когда нужны актуальные значения полей, можно обходиться без данного префикса.
Префикс "NEW_" означает новое значение поля и фактически имеет смысл только в запросах на изменение и вставку. Однако новые значения полей в этих ситуациях также являются и текущими, а значит, префикс "NEW_" можно опускать
Существует также специальный префикс "MAS_", но мы доберемся до него несколько позже.
Поскольку мы сгенерировали все необходимые модифицирующие запросы, то уже можем запустить наше приложение, добавить пару категорий, изменить их названия и даже целиком удалить их.
Тем не менее генерация модифицирующих запросов в design-time не всегда удобна FIBPIus позволяет разработчику автоматически генерировать нужные запросы во время работы приложения, основываясь на запросе из свойства SelectSQL Для этого нужно использовать свойство AutoUpdateOptions (рис 223).
Рис 2.23. Комплексное свойство AutoUpdateOptions
Необходимо "включить" ключ "AutoReWriteSqls", указать ключевое поле, которое будет использовано в условиях WHERE (в нашем случае, это поле "Id") и указать название модифицируемой таблицы ("Categories"), поскольку в реальности запросы могут быть многотабличными. Теперь свойства InsertSQL, DeleteSQL, UpdateSQL и RefreshSQL будут генерироваться автоматически при открытии CategonesDataSet. To есть фактически мы имеем генератор запросов в run-time, что бывает очень удобно.
Есть еще один момент, связанный с генерацией модифицирующих запросов Например, если мы редактируем только название категории, то после нажатия на Entei на сервер будет отправлен запрос, в котором изменены два поля и Name и GoodsCount Фактически же мы изменяли только одно поле - "Name".В итоге если запись таблицы содержит значительный объем данных (например, длинные строковые поля), то при малейшем исправлении даже одного поля на сервер будут "уходить" все данные. При многопользовательской работе это создаст дополнительный лишний трафик Данной ситуации можно избежать но для этого необходимо, чтобы приложение выполняло 6oлee эффективные изменяющие запросы, например запрос:
UPDATE "Categories" SET
"Name" = ."Name"
WHERE
"Id" = :"OLD_Id"
в котором, как вы видите, участвует только то поле, значение которого действительно было изменено. Такая возможность существует, если мы включим ключ UpdateOnlyModifiedFields (разумеется, этот ключ действует, только если мы используем режим генерации запросов в run-time). В случае редактирования только поля "Name" компонент CategoriesDataSet автоматически сгенерирует запрос, приведенный выше, и будет генерировать каждый раз новые запросы в зависимости от того, какие поля изменялись.
Поскольку теперь наш CategoriesDataSet стал модифицируемым, то мы можем написать обработчики событий OnClick у трех кнопок справа от CategoriesGrid:
procedure TMainForm AddCatButtonClick(Sender TObject);
begin
CategoriesDataSet Append;
end;
procedure TMainForm.EditCatButtonClick(Sender: TObject);
begin
CategoriesDataSet Edit;
end;
procedure TMainForm.DeleteCatButtonClick(Sender: TObject);
begin
if MessageDlg('Вы уверены, что хотите удалить категорию "' +
CategoriesDataSet.FieldByName('Name').AsString + '"?',
mtConfirmation,
[mbYes, mbNo], 0) = mrYes then
CategoriesDataSet.Delete;
end;
Компоненты-оболочки для Services API
Локальная фильтрация
Аналогично локальной сортировке, которая оперирует только с данными в локальном буфере, мы можем также выбирать записи из уже полученных по какому-либо критерию, скрывая от пользователя "лишние" записи.
Рассмотрим локальную фильтрацию на примере приложения Filtering. Этот пример включен в стандартную поставку FIBPlus. В примере используется база данных FIBPlus_Example.gdb (рис. 2.68).
Эта база данных в виде backup-файла доступна на сайте http://www.fibplus.net/
Рис 2.68. Использование локальной фильтрации TpFIBDataSet
Совершенно очевиден код для подключения к базе данных. Список элементов компонента FieldsC: TComboBox заполняется названиями полей из таблицы BIOLIFE.
FilteringDS.SelectSQL: SELECT * FROM BIOLIFE
procedure TMainForm.btnConnectClickfSender: TObject);
var Index: Integer;
begin
with MainDB do begin
ConnectParams.UserName := edtUserName.Text;
ConnectParams.Password := edtPassword.Text;
DBName := edtDataBase.Text;
try
Open;
FilteredDS.Open;
FieldsC.Items.Clear;
for Index := 0 to pred(FilteredDS.FieldCount) do
FieldsC.Items.Add(FilteredDS.Fields[Index].FieldName);
except
MessageDlgt'Error of connection to a database!', mtError, [mbOk], 0) ;
Close;
end;
end;
end;
Пользователь может выбрать поле из списка FieldsC, указать в поле FilterE: TEdit строку для поиска и после нажатия на кнопку Button I ("Activate Filter"):
procedure TMainForm.ButtonlClick(Sender: T0b3ect);
begin
FilteredDS.Filtered := false;
FilteredDS.Filtered := true;
end;
в DBGrid 1 останутся видны только те записи, которые содержат в заданном поле искомую строку Для этого нам необходимо написать обработчик события OnFilterRecord у FilteringDS: procedure TMainForm.FilteredDSFilterRecord(DataSet: TDataSet;
var Accept: Boolean); begin
Accept := DOS(FilterE.Text,
FilteredDS.FieldByName(FieldsC.Text).AsString) <> 0
end;
После включения FilteredDS.Filtered := true OnFilterRecord вызывается для каждой записи в локальном буфере. Если мы хотим, чтобы конкретная запись оставалась видимой, мы должны задать для нее параметр Accept равным True. Из примера кода видно, что мы оставляем видными только те записи, которые содержат в искомом поле (FieldsC.Text) заданную строку (FilterE.Text). Если мы, например, выберем поле COMMON_NAME и укажем строку для поиска "А", то в результате получим только две видимые записи (рис. 2.69).
Рис 2.69. Пример двух "отфильтрованных" записей
Поскольку наше условие для фильтра сформулировано таким образом, что мы выбираем записи по точному включению искомой подстроки - в нашем случае это только те записи, которые содержат большую букву "А". Мы можем немного усложнить условие поиска. Положим на форму CaseC: TcheckBox (см. рис. 2.69, "Case sensitive") и перепишем обработчик OnFilterRecord следующим образом:
procedure TMainForm.FilteredDSFilterRecord(DataSet: TDataSet;
var Accept: Boolean);
begin
if CaseC.Checked then
Accept := pos(FilterE.Text,
FilteredDS.FieldByName(FieldsC.Text).AsString) <> 0
else
Accept := pos(AnsiUpperCase(FilterE.Text),
AnsiUpperCase(FilteredDS.FieldByName(FieldsC.Text).AsString))
<> 0;
end;
Очевидно, что теперь если пользователь отключит "флажок" "Case sensitive", то фильтр по строке "А" будет содержать гораздо большее количество записей - все записи, которые содержат хотя бы одну букву "А", неважно маленькую или большую (рис. 2.70).
Рис 2.70. Записи, содержащие букву "А"
Очевидно, что использование локальной фильтрации дает разработчику в руки очень гибкое средство построения условий, поскольку этот механизм не столько ограничен, как SQL в условиях WHERE. На основе локальной фильтрации, например, очень легко создается механизм быстрого поиска записи по первым буквам, которые пользователь набирает в поле редактирования.
Локальная сортировка
Рассмотрим локальную сортировку на примере Sorting, который входит в поставку FIBPlus.
Как и все остальные примеры, приложение Sorting вы можете наши на сайте http://www.fibplus.net
Пример использует таблицу EMPLOYEE из базы данных Employee.gdb (рис. 2.67)
Рис 2.67. Внешний вид формы приложения, демонстрирующего локальную сортировку в TpFIBDataSet
MainDS.SelectSQL: SELECT * FROM EMPLOYEE
Все записи, полученные от сервера в результате запроса, сохраняются в локальном буфере компонента TpFIBDataSet.
Это одна из причин, из-за которой не рекомендуется использовать TpFIBDataSet для слишком больших выборок, - вам просто может не хватить оперативной памяти и работа приложения замедлится.
Предположим, что пользователь хочет отсортировать записи по полю FIRST_NAME. Очевидно, что мы можем сформировать новый запрос:
SELECT * FROM EMPLOYEE
ORDER BY FIRST_NAME
Чтобы получить новый порядок записей, необходимо переоткрыть наш запрос. Это работает, но означает, что мы будем повторно получать от сервера все •записи, несмотря на то что нам нужно было всего лишь поменять их визуальный порядок. Если предполагать, что нашим приложением могут пользоваться одновременно несколько пользователей, то затраты на подобные "сортировки" могут оказаться довольно значительными. Тем не менее выход существует, поскольку TpFIBDataSet позволяет сортировать данные внутри своего локального буфера, т. е. без необходимости получения всех записей заново.
Для этого мы должны воспользоваться одним из возможных вариантов метода DoSort или DoSortEx:
procedure DoSort(Fields: array of const; Ordering: array of Boolean); virtual;
procedure DoSortEx(Fields: array of integer; Ordering: array of Boolean); overload;
procedure DoSortEx(Fields: TStrings; Ordering: array of Boolean); overload;
Метод DoSortEx доступен в FIBPlus начиная с версии Delphi 4.
Первый параметр всех трех процедур - это список полей, по которым мы хотим отсортировать данные. В случае DoSort это могут быть названия полей или номера полей. Первый вариант DoSortEx позволяет нам использовать только список с номерами полей, а второй вариант DoSortEx предполагает, что мы заполнили список Fields названиями полей. Параметр Ordering во всех трех случаях указывает направление сортировки по каждому из полей. Таким образом, мы можем отсортировать наш запрос по полю FIRST_NAME следующим образом:
DoSort(['FIRSN_NAME'], [True]);
Или: DoSortEx([1], [True]);
[True] означает, что поле сортируется по возрастанию (ASCENDING).
В сущности, использование этих методов очевидно, однако иногда возникает вопрос, связанный с динамическим формированием списков полей. Рассмотрим подробнее наш пример, который демонстрирует, как создавать параметры для DoSortEx динамически. Предполагается, что пользователь сможет нажимать на заголовки DBGridl, указывая, таким образом, поле, которое будет участвовать в сортировке. Повторное нажатие на колонку, которая уже участвует в сортировке, будет изменять порядок сортировки по этой колонке на противоположный. Сначала мы опишем вспомогательный класс для хранения информации о молях, которые будут участвовать в сортировках.
type
TOrderStringList = class(TStringList)
protected
function GetAscending(Index: Integer): boolean;
procedure SetAscending (Index: Integer; Value: boolean);
public
property Ascending[Index: Integer]: boolean read GetAscending write SetAscending;
end;
...
{ TOrderStringList }
function TOrderStringList.GetAscending(Index: Integer):
boolean;
begin
Result := boolean(integer(Objects[Index]));
end;
procedure TOrderStringList.SetAscending(Index: Integer; Value:
boolean);
begin
Objects [ Index] := pointer (integer (Value));
end;
Очевидно, что данный класс является списком строк - названия полей, а также хранит для каждого поля, включенного в список, порядок сортировки в виде свойства Ascending. Ниже вы видите описание класса формы, а также два основных обработчика событий (OnCreate, OnDestroy). При создании формы мы создаем экземпляр класса TOrderStringList, а при ее уничтожении - удаляем.
TMainForm = class(TForm)
MainDB: TpFIBDatabase;
MainDS: TpFIBDataSet;
MainTr: TpFIBTransaction;
DataSourcel: TDataSource;
DBGridl: TDBGrid;
Buttonl: TButton;
Label2: TLabel;
procedure DBGridlTitleClick(Column: TColumn);
procedure FormCreate(Sender: TObject);
procedure FormDestroy(Sender: TObject);
procedure ButtonlClick(Sender: TObject);
private
{ Private declarations }
public
{ Public declarations }
SortFields: TOrderStringList;
procedure ReSort;
end;
procedure TMainForm.FormCreate(Sender: TObject);
begin
SortFields := TOrderStringList.Create;
end;
procedure TMainForm.FormDestroy(Sender: TObject);
begin
SortFields.Free;
end;
Теперь напишем обработчик события OnTitleClick у компонента DBGridl: procedure TMainForm. DBGndlTitleCiiCK (Column: TColumn);
const OrderScr: array [boolean] of string = ('(DESC)',
'(ASC) ') ;
var aField: string;
aFieldlndex: integer;
begin
aField := Column.FieldName;
aFieldlndex := SortFields.IndexOf(aField) ;
if aFieldlndex = -1 then begin
SortFields.Add(aField);
SortFields.Ascending[SortFields.Count - 1] := true;
Column.Field.Display-Label := Column. Field.FieldName + OrderStr[true];
end
else begin
SortFields.Ascending[aFieldlndex] := not
SortFields.Ascending[aFieldlndex];
Column.Field.Display-Label := Column.Field.FieldName +
OrderStr[SortFields.Ascending[aFieldlndex]];
end;
ReSort;
end;
Смысл обработчика состоит в следующем: при нажатии пользователем на заголовок мы проверяем, есть ли данное поле в нашем списке сортировки. Если нет, то мы добавляем его и формируем новый заголовок для колонки, который теперь будет состоять из названия поля и порядка сортировки (ASC) или (DESC). Если же поле уже было включено в сортировку, то мы лишь меняем порядок сортировки. В обоих случаях мы должны вызвать процедуру ReSort, описанную ниже:
procedure TMainForm.ReSort;
var Orders: array of boolean;
Index: Integer;
begin
if SortFields.Count = 0 then begin MainDS.CloseOpen(false);
exit;
end;
SetLength(Orders, SortFields.Count);
for Index := 0 to pred(SortFields.Count) do
Orders[Index] := SortFields.Ascending[Index];
MainDS.DoSortEx(SortFields, Orders);
end;
Данная процедура формирует списки для метода DoSortEx на основе списка SortFields и пересортировывает записи. В случае, если наш список сортировки пустой, мы должны вернуться к "стандартному" порядку записей. Для этого вызывается метод CloseOpen.
Параметр False означает, что мы не хотим автоматически получать сразу все записи от сервера.
Если наш список полей не пустой, то мы должны сформировать массив Orders. Это делается, как видно, достаточно легко. Используя динамические массивы, мы сначала задаем длину Orders равной количеству полей в списке SortFields, а потом последовательно заполняем Orders значениями свойства Ascending списка SortFields. Остается только вызвать метод DoSortEx - и сортировка б\дет выполнена.
Чтобы закрыть вопрос целиком, нам остается только предоставить пользователю возможность исключать поля из сортировки. Для этого мы положим на форму кнопку Button 1 (см. рис. 46, заголовок "Delete column from Sorting"):
procedure TMainForm.ButtonlClick(Sender: TObject);
var aField: string;
aFieldlndex: integer;
begin
aField := DBGridl.SelectedField.FieldName;
aFieldlndex := SortFields.IndexOf(aField);
if aFieldlndex <> -1 then begin
SortFields.Delete(aFieldlndex);
DBGridl.SelectedField.DisplayLabel := aField;
ReSort;
end;
end;
Пользователь выделяет поле, которое хочет удалить из сортировки, и нажимает на кнопку "Delete column from Sorting", после чего это поле удаляется из списка SortFields и производится пересортировка записей.
Локальная сортировка и локальная фильтрация
TpFIBDataSet позволяет разработчику оптимизировать работу с базой данных, используя в случае необходимости локальную сортировку данных и локальную фильтрацию. Термин "локальный" в данном случае означает, что в этих механизмах не используются дополнительные запросы к серверу. Таким образом, в определенных случаях вы можете значительно снизить сетевой трафик вашего приложения, а также увеличить скорость поиска или сортировки данных.
Механизм master-detail
Механизм мастер-деталь часто используется в приложениях для работы с базами данных, поскольку именно он позволяет нам легко связывать данные из разных таблиц, полученных в результате нормализации базы.
Добавим на нашу форму новые компоненты (рис. 2.12).
IBDataSet2: TIBDataSet;
DataSource2: TdataSource;
DBGrid2: TDBGrid;
Рис 2.12. Разработка связи мастер-деталь
Свяжем DataSource2 с IBDataSet2, a DBGrid2 с DataSource2. Укажем следующие запросы для IBDataSet2:
SelectSQL:
SELECT BUDGET, DEPARTMENT, DEPT_NO, HEAD_DEPT, LOCATION,
MNGR_NO, PHONE_NO
FROM DEPARTMENT
InsertSQL:
INSERT INTO DEPARTMENT
(BUDGET, DEPARTMENT, DEPT_NO, HEAD_DEPT, LOCATION, MNGR_NO,
PHONE_NO)
VALUES
(:BUDGET, :DEPARTMENT, :DEPT_NO, :HEAD_DEPT, :LOCATION,
:MNGR_NO, :PHONE_NO)
DeleteSQL:
DELETE FROM DEPARTMENT
WHERE DEPT_NO = :OLD_DEPT_NO
ModifySQL:
UPDATE DEPARTMENT SET
BUDGET = :BUDGET,
DEPARTMENT = :DEPARTMENT,
DEPT_NO = :DEPT_NO,
HEAD_DEPT = :HEAD_DEPT,
LOCATION = :LOCATION,
MNGR_NO = :MNGR_NO,
PHONE_NO = :PHONE_NO WHERE
DEPT_NO = :OLD_DEPT_NO
RefreshSQL:
SELECT
DEPT_NO,
DEPARTMENT,
HEAD_DEPT,
MNGR_NO,
BUDGET,
LOCATION,
PHONE_NO,
DEPT_NO1 FROM DEPARTMENT WHERE
DEPT_NO = :DEPT_NO
Очевидно, что их можно сгенерировать при помощи DataSet Editor, как это было описано выше
Теперь необходимо внести изменения в IBDataSetl. Во-первых, нужно задать свойство IBDataSetl.DataSource равным DataSource2. Во-вторых, надо изменить IBDataSetl. SelectSQL:
SELECT DEPT_NO, EMP_NO, FIRST_NAME, FULL_NAME, HIRE_DATE,
JOB_CODE, JOB_COUNTRY, JOB_GRADE, LAST_NAME, PHONE_EXT, SALARY
FROM EMPLOYEE
WHERE DEPT_NO = :DEPT_NO
Значение параметра :DEPT_NO будет автоматически браться из одноименного поля IBDataSet2: DEPT_NO.
Запустите приложение, и вы увидите, что при перемещении по верхней таблице в нижней будут отображаться только сотрудники текущего отдела (рис. 2.13).
Еще одна особенность заключается в том, чтобы настроить IBDataSetl таким образом, что при добавлении новой записи о работнике автоматически подставлялся номер текущего отдела из IBDataSet2. Для этого напишем обработчик OnNewRecord у IBDataSetl:
procedure TForml.IBDataSetlNewRecord(DataSet: TDataSet);
begin
DataSetl.FieldByName('DEPT_NO').Aslnteger :=
IBDataSet2.FieldByName('DEPT_NO').Aslnteger;
end;
Puc 2.13. Запущенное приложение со связью мастер—деталь
Теперь мы можем смело запускать приложение и редактировать записи в обеих таблицах.
Хочется отметить, что в соответствующей главе, посвященной механизму мастер-деталь в FlBPlus, описаны дополнительные возможности компонентов, связанные с оптимизацией и "тонкой" настройкой связей мастер-деталь, которые отсутствуют в IBX Возможно, что, ознакомившись с этим описанием, вы реализуете в своем приложении нечто подобное и при помощи IBX
Также хочется отметить, что компоненты IBX предоставляют все необходимые базовые возможности для создания приложений практически любого уровня сложности.
Важно лишь понимать, какой компонент желательно применять в конкретной ситуации. Например, для массовых вставок записей в базу данных, если нет нужды отображать вставляемые записи в пользовательских компонентах, желательно использовать IBSQL, которые не буферизуют записи в отличие от TIBDataSet и его потомков.
При использовании для этой же операции TIBDataSet при большом количестве записей (порядка нескольких миллионов) приложение может начать работать на порядки медленнее.
Важно отметить, что работа с большим количеством записей для пользователя редко бывает удобной. Согласитесь, не так часто можно найти человека, который смог бы удержать в памяти информацию из нескольких сотен записей.
Обычно пользователи все-таки применяют поиск, чтобы найти нужные данные, и задача разработчика, помимо прочего, состоит в том, чтобы формулировать условия в SQL-запросах максимально точно и иметь в итоге лишь небольшой набор данных. Во-первых, это резко снизит лишний сетевой трафик, а во- вторых, снизит размер памяти, занимаемой данными в буфере TIBDataSet, за счет чего также увеличится скорость работы TIBDataSet.
Управление транзакциями тоже зависит только от вас и требований вашей задачи. Не существует единственно правильного способа распределения компонентов TIBTransaction. Некоторые предпочитают все делать в контексте одной общей транзакции, вовремя вызывая Commit или Rollback; другие предпочитают для каждого TIBDataSet иметь отдельную транзакцию, следя за правильным уровнем изоляции. Только вы можете решить, какие транзакции нужны для правильной работы ваших запросов.
Механизм master-detail. Специальные опции TpFIBDatabase и TpFIBDataSet
Мы имеем возможность редактировать данные о категориях товаров и можем переходить к вопросам, связанным с построением связки master-detail. Для этого мы положим на форму дополнительные компоненты:
GoodsSource: TDataSource;
GoodsGrid: TDBGrid;
GoodsDataSet: TpFIBDataSet;
GoodsReadTransaction: TpFIBTransaction;
GoodsWriteTransaction: TpFIBTransaction;
AddGoodsButton: TButton;
EditGoodsButton: TButton;
DeleteGoodsButton: TButton;
"Свяжем" их так же, как и предыдущую группу компонентов, и напишем SelectSQL для GoodsDataSet:
SELECT * FROM "Goods"
WHERE "IdCategory" = :"Id"
Очевидно, что мы хотим выбрать при помощи detail-запроса только те товары, которые относятся к текущей категории. Значение параметра : "Id" должно браться из поля "Id" таблицы "Categories". Чтобы это происходило автоматически, необходимо задать свойство GoodsDataSet.DataSource равным CategoriesSource. Теперь сгенерируем модифицирующие запросы для GoodsDataSet так же, как мы делали это раньше для CategoriesDataSet.
После автоматической генерации мы должны внести некоторые изменения в полученные запросы. Рассмотрим, в частности, запрос для InsertSQL:
INSERT INTO "Goods"(
"Id",
"Name",
"Price",
"IdCategory" )
VALUES(
:"Id",
:"Name",
:"Price",
:"IdCategory"
)
Очевидно, что при добавлении нового товара, мы должны задать параметр : "IdCategory" текущим значением поля "Id" из таблицы "Categories". FIBPlus позволяет делать это автоматически при помощи префикса "MAS_", о котором мы уже упоминали выше:
INSERT INTO "Goods"(
"Id" ,
"Name",
"Price",
"IdCategory" )
VALUES(
:"Id",
:"Name",
:"Price",
:"MAS_Id"
)
Теперь мы указали явным образом, что значение для поля "Goods"."IdCategory" нужно брать из поля "Id" таблицы "Categories", которая является master- таблицей для таблицы "Goods". To же изменение необходимо внести в запрос UpdateSQL
UPDATE "Goods" SET
"Id" = :"Id",
"Name" = :"Name",
"Price" = :"Price",
"IdCategory" = :"MAS_Id"
WHERE
"Id" = 'OLD_Id"
Теперь изменим немного код в процедуре FormCreate:
procedure TMainForm.FormCreate(Sender: TObject);
begin
with TimFile. Create (' ib_price. mi ') do begin
pFIBDatabasel.DBName := ReadStringt'Options', 'DBPath',
'C:\IBPRICE.GDB');
Free;
end;
pFIBDatabasel.Open;
CategoriesDataSet.Open;
GoodsDataSet.Open;
end;
He забудем заполнить свойства AutoUpdateOptions, чтобы GoodsDataSet автоматически генерировал значения первичного ключа (рис 2 27)
Можно запустить приложение Двигаясь вверх и вниз по CategoriesGrid, вы можете наблюдать, как автоматически изменяется содержимое в GoodsGrid Связка master-detail уже работает.
FIBPlus позволяет также настраивать некоторые особенности работы механизма master-detail. В частности, как вы уже обратили внимание, в нашем примере мы открывали detail-dataset (GoodsDataSet) "вручную", при помощи явного вызова метода Open В случае с простой связкой это нетрудно, однако если мы используем несколько цепочек master-detail или более длинные цепочки - master-detail-subdetail, то ручное открытие всех запросов может даже привести к ошибке. Вы всегда должны открывать подчиненный запрос после основного.
Чтобы избежать ненужного и совершенно очевидного кодирования, TpFEBDataSet содержит специальное свойство DetailConditions (рис. 2.28).
Рис 2.27. Использование AutoUpdateOptions длл генерации значений первичного ключа GoodsDdtabet
Рис 2.28. Свойаво DetailConditions
Задав ключ dcForceOpen. мы можем быть совершенно уверены, что detail- запрос будет автоматически открыт после открытия master-запроса. Теперь мы можем удалить строку GoodsDataSet.Open из метода CreateForm. Какова бы ни была глубина связок master-detail, все запросы будут открыты в нужном порядке.
Вторая важная опция - это ключ dcWaitEndMastei Scroll Представьте, что пользователь передвигается по CategonesGrid, пытаясь найти нужную категорию товаров. При каждом движении, когда меняется текущая запись в CategoriesGrid, GoodsDataSet автоматически открывает запрос заново. Очевидно, движение по mastei-таблице может вызвать серию довольно "тяжелых" запросов, которые значительно увеличат совершенно бесполезный сетевой трафик. На практике было нужно переоткрыть detail-запрос только один раз, когда пользователь все-таки нашел нужную ему категорию в CategoriesGrid. FIBPlus позволяет избежать ненужных запросов. Если ключ dcWaitEndMasterScroll добавлен в DetailConditions, то detail-запрос переоткрывается только после некоторой паузы (величину паузы можно регулировать, задавая значение свойства WaitEndMasterlnterval).
Таким образом, когда пользователь просто передвигается по CategoriesGrid, изменение текущей записи "включает" таймер detail-запроса. Если за время паузы пользователь успевает перейти на другую запись, то таймер сбрасывается. И так до тех пор, пока пользователь не остановится на нужной записи. Только после этого detail-запрос переоткрывается, а значит, GoodsDataSet выполняет только один запрос вместо целой серии.
Третий важный ключ в DetailConditions управляет поведением master- таблицы при изменении detail-таблицы. В нашем примере в таблице "Categories" существует поле "GoodsCount", в котором содержится количество наименований товаров для текущей категории. Когда мы добавляем или удаляем наименование товара из категории, то это значение должно меняться. Очевидно, что данный механизм легко реализуется парой триггеров для таблицы "Goods":
CREATE TRIGGER "Goods_AI" FOR "Goods" ACTIVE
AFTER INSERT POSITION 0
AS
BEGIN
update "Categories" set
"GoodsCount" = (select count("Id") from "Goods" where
"IdCategory" = New."IdCategory")
where "Id" = New."IdCategory";
END^
CREATE TRIGGER "Goods_BD" FOR "Goods" ACTIVE
BEFORE DELETE POSITION 0
AS
BEGIN
update "Categories" set
"GoodsCount" = (select count("Id") from "Goods" where
"IdCategory" = Old."IdCategory")
where "Id" = Old."IdCategory";
END^
Давайте рассмотрим последовательность происходящих действий, например при добавлении нового наименования товара для какой-то категории.
В GoodsDataSet формируется значение ключевого поля "Id" при помощи генератора.
Значения полей заполняются пользователем.
После нажатия пользователем клавиши Enter GoodsData подготавливает запрос из свойства InsertSQL к выполнению и заполняет значения параметров соответствующими значениями полей.
Параметр :"IdCategory" заполняется текущим значением поля "Id" из CategoriesDataSet.
Запрос выполняется и выполняется триггер "Goods_AI".
Транзакция GoodsWriteTransaction автоматически подтверждает сделанные изменения при помощи метода Commit.
Выполняется запрос из свойства RefreshSQL, который перечитывает значения полей вставленной в таблицу "Goods" записи, основываясь на известном значении ключевого поля "Id".
В этот момент значение поля "GoodsCount" уже изменилось, но это изменение никак не отражается в CategoriesGrid. Мы должны обновить текущую запись в CategoriesDataSet, чтобы увидеть актуальное значение всех полей. Это можно сделать при помощи явного вызова метода CategoriesDataSet.Refresh. Однако этот же метод нам надо будет вызывать и в случае удаления записи из GoodsDataSet. А если бы нам нужно было создать более сложный механизм взаимодействия между master и detail-таблицами, то, скорее всего, метод Refresh нужно было бы вызывать также и после многих других операций.
Вместо всего этого мы можем просто добавить ключ dcForceMasterRetresh. Этот ключ автоматически вызывает метод Refresh у master, если detail была изменена. Если вы запустите приложение, то сами увидите, что значение поля "GoodsCount" автоматически изменяется при добавлении и удалении записей в GoodsDataSet.
"Низкоуровневая" работа с внутренним буфером TpFIBDataSet
TpFIBDataSet включает несколько специальных методов для работы с внутренним буфером, в котором хранятся записи. В общем-то, данные методы превращают TpFIBDataSet в аналог TClientDataSet, ориентированный на InterBase. Наиболее интересным примером использования данных методов будет, пожалуй, построение диалога выбора, состоящего из двух списков (рис. 2.75).
Рис 2.75. Использование локального кеша TpFIBDataSet для организации двойного списка выбора
В данном примере мы будем использовать базу данных EMPLOYEE.GDB, входящую в стандартную поставку InterBase и FIBPlus. Покажем запросы для SourceDS:
SelectSQL:
SELECT
CUS.CUST_NO,
CUS.CUSTOMER
FROM
CUSTOMER CUS
ORDER BY CUS.CUSTOMER
UpdateSQL:
UPDATE CUSTOMER SET
CUSTOMER = ?CUSTOMER
WHERE
CUST_NO = ?OLD_CUST_NO
InsertSQL:
INSERT INTO CUSTOMER(
CUST_NO,
CUSTOMER
)
VALUES(
?CUST_NO,
?CUSTOMER
)
DeleteSQL:
DELETE FROM CUSTOMER
WHERE
CUST_NO = ?OLD_CUST_NO
RefreshSQL:
SELECT
CUS.CUST_NO,
CUS.CUSTOMER
FROM
CUSTOMER CUS
WHERE
(
CUS.CUST_NO = ?OLD_CUST_NO
)
Те же самые запросы мы будем использовать в TargetDS, поскольку оба компонента должны обладать совместимой структурой полей. Откроем оба запроса сразу после создания формы:
procedure TDualListForm.FormCreate(Sender: TObject);
begin
SourceDS.Open;
TargetDS.CacheOpen;
end;
Если мы не указываем в коде явного открытия базы данных, то это означает, что свойство Connected > компонета TpFlBDatabase было задано в True в design-time.
Обратите внимание на то, что TargetDS мы активируем при помощи специального метода CacheOpen. Этот метод не выполняет запрос из SelectSQL, а только подготавливает внутренний буфер компонента в зависимости от запроса в SelectSQL. Очевидно, что после запуска приложения мы увидим записи в левом списке и пустую таблицу в правом. Теперь мы можем написать процедуру, которая позволит переносить записи из одного списка в другой:
procedure TDualListForm.MoveRec(Select: Boolean);
begin
if Select then begin
if (SourceDS.Active) and (not SourceDS.IsEmpty) then begin
TargetDS.CacheRefreshByArrMap(SourceDS, frklnsert,
['CUST_NO'], ['CUST_NO']);
SourceDS.CacheDelete;
end;
end
else begin
if (TargetDS.Active) and (not TargetDS.IsEmpty) then begin
SourceDS.CacheRefresh(TargetDS, frklnsert, nil);
TargetDS.CacheDelete;
end;
end;
end;
Если параметр Select равен True, то мы будем переносить текущую запись из левого списка в правый, т. е. из SourceDS в TargetDS. Рассмотрим подробнее метод CacheRefreshByArrMap.
procedure CacheRefreshByArrMap(FromDataSet: TDataSet; Kind:
TCachRefreshKind; const SourceFields, DestFields: array of
String);
Метод позволяет вставлять или модифицировать текущую запись в локальный буфер компонента, т. е. без выполнения соответствующих модифицирующих запросов. Параметр FromDataSet указывает, из какого TpFIBDataSet мы хотим получить запись. Параметр Kind может принимать два значения: frkEdit или frklnsert. Frklnsert указывает, что мы хотим вставить новую запись, a frkEdit - что мы хотим изменить существующую. Параметр SourceFields описывает список полей из компонента источника, а список DestFields - список полей в TpFIBDataSet-приемнике. Формально названия полей в списках могут не совпадать, но необходимо, чтобы совпадали типы данных, иначе обмен данными будет невозможен. В нашем примере, как вы можете видеть, мы вставляем в TargetDS текущую запись из SourceDS. Данный метод использован здесь только для демонстрации, поскольку мы вполне могли бы обойтись методом CacheRefresh, который копирует соответствующие поля автоматически. После вставки записи необходимо удалить ее из компонента источника. Это делается при помощи метода CacheDelete, который также не выполняет соответствующий запрос (DeleteSQL), а удаляет запись только из локального буфера в памяти. Теперь, когда мы знаем, что делают процедуры CacheRefreshByArrMap, CacheRefresh и CacheDelete, код процедуры достаточно очевиден: мы копируем запись из компонента-источника в компонент-приемник и удаляем ее из компонента-источника.
То же самое можно сделать в цикле, если мы хотим перенести все записи сразу:
procedure TDualListForm.MoveAll(Select: Boolean);
var TmpDataSet: TpFIBDataSet;
begin
if Select then TmpDataSet := SourceDS else
TmpDataSet := TargetDS;
with TmpDataSet do begin
try
DisableControls;
First;
while not Eof do MoveRec(Select);
finally
EnableControls;
end;
end;
end;
Остается написать обработчики события OnClick для кнопок:
procedure TDualListForm.ButtonlClick(Sender: TObject);
begin
MoveRec(True); // SourceDS -> TargetDS
end;
procedure TDualListForm.Button2Click(Sender: TObject);
begin
MoveRec(False); // TargetDS -> SourceDS
end;
procedure TDualListForm.Button3Click(Sender: TObnect);
begin
MoveAll(True), // SourceDS -> TargetDS
end;
procedure TDualListForm. Button4Click (Sender : TObject) ;
begin
MoveAll(False); // TargetDS -> SourceDS
end;
Мы можем запустить наше приложение (рис 2.76)
Если мы будем нажимать на кнопку Button 1, то записи будут переноситься из левого списка в правый (рис. 2 77).
Все операции осуществляются только с данными внутри локальных буферов, не затражвают сервер и реальные данные в базе Наряду с описанными выше методами вы также можете использовать.
OpenAsCIone - открыть DataSet и скопировать данные из другого DataSet
CacheAppend - добавить запись в конец локального буфера.
SwapRecords - обменять записи в локальном буфере.
CacheEdit - задать значения полей у записи в локальном буфере.
Cachelnsert - вставить запись в локальный буфер
CacheModify - общий метод для вставки и изменения записи в локальным буфере
LoadFromFile - заполнить локальный буфер записями из файла.
LoadFromStream - заполнить локальный буфер записями из потока.
SaveToFile - сохранить локальный буфер в файл.
SaveToStream - сохранить локальный буфер в потоке
Функции работы с локальным буфером предоставляют разработчику чрезвычайно гибкое средство манипуляции данными в клиентских приложениях, позволяя улучшать наглядность пользовательского интерфейса без выполнения дополнительных запросов к базе данных
Рис 2.76. Внешний вид запущенного приложения
Рис 2.77. Внешний вид приложения при выборе пользователем трех записей
Обработка потери подключения к базе данных
Корректная обработка потери подключения к базе данных является одной из проблем при разработке устойчивых приложений вообще и, пожалуй, самым важным вопросом при разработке приложения, которое будет работать в условиях нестабильного канала связи (в частности, при использовании dial-up).
FIBPIus предоставляет разработчику полный набор средств для обработки потери подключения: возможность аккуратно закрыть все приложение, "закрыть" (т. е. деактивировать все соответствующие компоненты) само подключение на уровне приложения или попробовать восстановить подключение без закрытия запросов.
Ключевым компонентом для обработки ситуации является TpFTBErrorHandler. Формально, потерю подключения мы будем обрабатывать при помощи компонента TpFIBDatabase в обработчике события OnLostConnect, однако без "глубокого" перехвата в TpFIBErrorHandler мы не сможем избавиться от лишних сообщений о потере подсоединения.
Итак, попробуем создать простое приложение, позволяющее редактировать данные в TDBGrid и обрабатывать потерю подключения к базе данных тремя способами, про которые уже было упомянуто (рис. 2.57).
Рис 2.57. Внешний вид главной формы примера Connection Lost
Заполним SelectSQL для CompaniesDataSet: select * from "Companies" и предоставим CompaniesDataSet самостоятельно генерировать модифицирующие запросы (рис. 2.58).
Рис 2.58. Свойства AutoUpdateOptions компонента CompaniesDataSet
Включим также режим CachedUpdates (CompaniesDataSet.CachedUpdates := True), чтобы корректно обрабатывать восстановление подключения без потери данных.
Компонент cmbKindOnLost: TComboBox будет содержать список возможных реакций на потерю подключения, чтобы мы могли во время выполнения приложения попробовать все возможности:
Close pFIBDataBase
Terminate application
Restore connect
Теперь обратим внимание на компонент pFIBErrorHandlerl (рис. 2.59).
TpFIBErrorHandler обрабатывает "особым" образом два типа ошибок: пользовательские исключения и потерю подключения к базе данных. В компонент заложена также возможность обработки ошибок, связанных с нарушением ссылочной целостности, однако в существующих версиях FIBPlus данная функция еще не реализована.
TpFIBErrorHandler имеет только одно событие - OnFIBErrorEvent, обработка которого позволит нам обработать, в частности, потерю подключения к базе данных:
procedure TForml.pFibErrorHandlerlFIBErrorEvent(Sender:
TObject;
ErrorValue: EFIBError; KindlBError: TKindlBError; var
DoRaise: Boolean);
begin
if KindlBError = keLostConnect then begin
DoRaise := false;
Abort;
end;
end;
Puc 2.59. Свойства компонента pFIBErrorHandlerl
Вот в общем-то и весь обработчик - мы просто запрещаем вывод стандартного сообщения о потере подключения. На практике вы сможете использовать OnFIBEnorEvent для более сложной обработки разного рода исключительных ситуаций, используя значение параметра ErrorValue. Для нашего случая важно также знать что, кроме срабатывания QnFIBErrorEvent, TpFIBErrorHandler инициирует возникновение OnLostConnection у компонентов TpFIBDatabase Именно здесь мы и сосредоточим основную обработку потери подсоединения.
procedure TForml.DatabaseLostConnect(Database: TFIBDatabase; E:
EFIBError;
var Actions: TOnLostConnectActions);
begin
AttemptRest := 0;
case cmbKindOnLost.Itemlndex of 0: begin
Actions := laCloseConnect;
MessageDlg('Connection lost. TpFIBDatabase will be closed'',
mtlnformamon, [mbOk] , 0
);
end;
1: begin
Actions := laTerminateApp;
MessageDlg('Connection lost. Application will be closed',
mtlnformation, [mbOk], 0
);
end;
2: Actions := laWaitRestore;
end;
end;
Смысл обработчика очевиден - в зависимости от выбранного пользователем значения компонента cmbKindOnLost наше приложение либо "закрывает" активное подключение и все соответствующие компоненты, либо закрывает все приложение, либо включает режим восстановления подсоединения. Первые два случая очевидны и в общем-то не требуют никаких дополнительных шагов, кроме установления значения параметра Actions. Более подробно мы остановимся на восстановлении подключения.
Поскольку CompaniesDataSet находится в режиме CachedUpdates, то потеря подключения не влияет на возможность редактирования данных пользователем, поскольку все изменения будут сохраняться в локальном буфере компонента CompaniesDataSet Таким образом, в задачу TpFIBDataBase входит только одно: периодически пытаться восстано'вить подключение и сообщать об удачных и неудачных попытках. Когда подсоединение будет восстановлено, мы просто применим "отложенные" изменения к данным в базе данных Конечно, никто не гарантирует, что отложенные команды смогут быть выполнены сервером, поскольку на момент восстановления подключения наши локальные данные могут совершенно потерять актуальность.
Итак, напишем два простых обработчика Первый для события Database OnErrorRestoreConnect
procedure TForml.DatabaseErrorRestoreConnect(Database:
TFIBDatabase;
E: EFIBError; var Actions: TOnLostConnectActions);
begin
Inc(AttemptRest);
Label4.Caption := IntToStr(AttemptRest);
Label4.Refresh;
end;
Компонент Label4 будет показывать счетчик попыток восстановления подсоединения. Второе событие, которое нас интересует, - AfterRestoreConnect:
procedure TForml DatabaseAfterRestoreConnect;
begin
MessageDlg('Connection restored. You can apply cached updates',
mtlnformation, [mbOk], 0
) ;
end;
Как только подключение к базе восстановлено, мы получим сообщение и сможем применить все сделанные изменения.
procedure TForml.ButtonlClick(Sender: TObject);
begin
with CompaniesDataSet do
try
if not DataBase.Connected then begin
try
DataBase.Connected . = True;
except
MessageDlg('Can''t restore connect',
mtlnformation, [mbOk], 0
);
Exit;
end
end;
if not Transaction.Active then Transaction StartTransaction;
ApplyUpdToBase;
Transaction.CoimutRetaining;
CommitUpdToCach;
except
if Transaction.Active then Transaction.RollBack;
end;
end;
На практике вы можете автоматически вызывать процедуру применения данных сразу из обработчика AfterRestoreConnect. В самой процедуре следует обратить внимание на методы ApplyUpdToBase и CommitUpdToCach. В отличие от стандартного метода ApplyUpdates, наследованного от TDataSet, который "не замечает" скрытые в результате локальной фильтрации записи (более подробно этот вопрос будет рассмотрен в разделе "Локальная фильтрация"), методы ApplyUpdToBase и CommitUpdToCach позволяют обойти эту ошибку VCL
Обработка событий InterBase при помощи FIBPIus
InterBase дает разработчику некоторый механизм для синхронизации приложений в многопользовательской среде Event Alerts. Суть данного механизма состоит в том. что вы можете вызывать пользовательские события из триггеров или хранимых процедур при помощи функции POST_EVENT:
CREATE PROCEDURE SHOW_EVENT(
EVENT_ID INTEGER)
AS
BEGIN
IF (:EVENT_ID = 1) THEN POST_EVENT 'TEST_EVENT1';
IF (.EVENT_ID = 2) THEN POST_EVENT 'TEST_EVENT2';
IF (.EVENT_ID = 3) THEN POST_EVENT 'TEST_EVENT3';
EXIT;
END
Создадим приложение (рис 2.71), которое будет вызывать данную процедуру и получать соответствующие события Если вы впоследствии попробуете запустить это приложение на двух компьютерах, то оба приложения будут получать сообщения вне зависимости оттого, кто их инициировал
Рис 2.71. Использование InterBase events, при помощи компонента TSIBfibEventAlerter
Для вызова хранимой процедуры мы будем использовать специальный компонент pFIBStoiedPioc TpFIBStoredPioc, задав свойство StoiedProcName (рис 2.72)
Рис 2.72. Вызов хранимой процедуры при помощи компонента TpFIBStoredPioc
Компонент TpFIBStoredProc является прямым потомком TpFIBQuery и сам формирует свойство SQL в виде ' EXECUTE PROCEDURE ...' Название процедуры задается свойством StoiedProcName
Компонент SffifibEventAlerterl: TSffifibEventAlerterlпредназначен для получения приложением событий InterBase Компонент ссылается на конкретное подключение к базе данных, т.е. на компонент типа TpFIBDatabase (рис 2.73)
Рис 2.73. Свойства SIBfibEventAlerterl
Установим свойство AutoRegister в False, чтобы собственноручно зарегистрировать нужные нам события, а в свойстве Events перечислим те события, которые нас интересуют (рис. 2.74).
Рис 2.74. Список зарегистрированных событий
Чтобы компонент SIBfibEventAlerterl "получал" события, мы должны зарегистрировать их после подключения к базе данных. Для этого напишем обработчик события OnConnect у компонента pFIBDatabasel:
procedure TForml.pFIBDatabaselConnect(Sender: TObject);
begin
if not SIBfibEventAlerterl.Registered then
SIBfibEventAlerterl.RegisterEvents;
end;
Соответственно перед закрытием подключения желательно "отключить" SIBfibEventAlerterl. Для этого создадим обработчик события BeforeDisconnect компонента pFIBDatabasel:
procedure TForml.pFIBDatabaselBeforeDisconnect(Sender:
TObject);
begin
if SIBfibEventAlerterl.Registered then
SIBfibEventAlerterl.UnRegisterEvents;
end;
Зададим свойство Tag у кнопок равным соответственно 1, 2 и 3, и напишем общий обработчик события OnClick для них:
procedure TForml.ButtonsClick(Sender: TObject);
begin
if not pFIBTransactionl.InTransaction then
pFIBTransactionl.StartTransaction;
pFIBStoredProcl.Params[0].Aslnteger := TButton(Sender).Tag;
try
pFIBStoredProcl.ExecProc;
pFIBTransactionl.Commit;
except
pFIBTransactionl.Rollback;
end;
end;
Смысл кода очевиден - мы задаем значение параметра процедуры, используя свойство Tag у кнопки, на которую нажал пользователь, выполняем процедуру при помощи метода ExecProc и либо подтверждаем транзакцию, либо отменяем ее в случае ошибки. Нам остается только написать обработчик события OnEventAlert компонента SIBfibEventAlerterl:
procedure TForml . SIBf ibEvent Alerter 1 Event Alert (Sender : TObject ;
EventName: String, EventCount: Integer);
begin
ShowMessage(EventName + ' : ' + IntToStr(EventCount));
end;
Параметр EventName возвращает название произошедшего события, a EventCount возвращает количество событий EventName. Значение параметра EventCount требует некоторых разъяснений. Итак, при работе с событиями важно помнить, что реально они вызываются только в случае подтверждения транзакции. Иными словами, если вы вызываете некоторое событие 'NEW_CUSTOMER' при вставке записей в таблицу, и вызываете Commit только после вставки 1000 записей, то обработчик OnEventAlert будет вызван только один раз, сразу после Commit, и значение параметра EventCount будет равно 1000. Очевидно, что событие произошло 1000 раз, но приложение получает нотификацию обо всех событиях только после подтверждения транзакции, в контексте которой они происходили.
Мы можем запустить наше приложение. При нажатии на любую из кнопок мы будем получать сообщение о произошедшем событии, причем, как уже было сказано, если наше приложение запущено несколько раз и даже на разных компьютерах, все копии приложения будут получать нотификацию о событиях.
Общее описание компонент, включенных в состав FIBPIus
TpFIBDatabase - предназначен для подключения к базе данных, позволяет получать статистическую информацию о базе, свойствах базы данных и так далее. Основные методы: Open, Close.
TpFIBTransaction - предназначен для явного управления транзакцией. Основные методы: StartTransaction, Commit, Rollback, CommitRetaining, RollbackRbtainine.
TpFIBDataSet - предназначен для получения и редактирования данных, является потомком стандартного класса TDataSet и полностью совместим со всеми визуальными компонентами. Основные методы: Prepare, Open, Close, Insert, Append, Edit, Delete, Refresh.
TpFIBQuery - предназначен для простого выполнения запросов, позволяет также получать данные из базы данных. В отличие от TpFIBDataSet , компонент не содержит локального буфера для хранения всех полученных записей, и не совместим с визуальными компонентами. Основные методы: Prepare, ExecOuery, Close
TpFIBStoredProc - потомок TpFIBQuery, предназначен для выполнения хранимых процедур. Не рекомендуется для вызова процедур, возвращающих данные. Фактически, компонент является удобной "оберткой" вокруг команды EXECUTE PROCEDURE.
TpFIBUpdateObject - предназначен для автоматического выполнения дополнительных модифицирующих действий совместно с TpFIBDataSet.
TDataSetContainer - предназначен для централизации обработки типичных обработчиков событий TpFIBDataSet и внутренней нотификации, что иногда позволяет сильно упростить код.
TpFIBSQLMonitor - предназачен для отслеживания всех запросов, которые выполняются при помощи компонентов FIBPIus. Позволяет также отслеживать запросы из параллельных приложений, также написанных на основе FIBPIus.
TpFIBErrorHandler - предназначен для централизованной обработки исключительных ситуаций, возникших при работе с функциями InterBase API. Позволяет обрабатывать потерю подключения к базе данных, инициализацию пользовательских исключений в самой базе данных.
SuperlBAlerter - предназначен для регистрации и получения событий (event alerters) InterBase.
TIBConfigService - предназначен для настройки параметров базы данных.
TIBBackupService предназначен для создания резервных копий (backup) баз данных.
TpFIBRestoreService - предназначен для восстановления базы данных из резервной копии.
TpFIBValidationService - предназначен для проверки целостности базы данных и согласования внутренних данных о транзакциях.
TpFIB Statistical Service - предназначен для получения статистики о базе данных.
TpFIBLogService - предназначен для создания и просмотра лог-файла работы сервера.
TpFIBSecurityService - предназначен для редактирования списка пользователей на сервере.
TpFIBLicensingService - предназначен для добавления и удаления сертификатов, регулирующих количество и свойства клиентских подключений к серверу InterBase.
TpFIBServerProperties - предназначен для получения информации о сервере, параметров конфигурации и так далее.
TpFIBInstall предназначен для установки компонента InterBase installation.
TpFIBUnlnstall - предназначен для установки компонента InterBase un- installation.
Общее описание основных компонентов, включенных в состав IBX
TIBTransaction - предназначен для явного управления транзакцией. Основные методы: StartTransaction, Commit, Rollback, CommitRetaining, RollbackRetaining.
TIBTable - аналог стандартного TTable. Компонент предназначен для получения данных из одной таблицы или представления базы данных. Основное свойство - TableName. Основные методы: Open, Close. Набор данных, полученных при помощи TIBTable, является редактируемым, если речь идет о таблице базы данных или обновляемом представлении. Компонент совместим с визуальными компонентами.
TIBQuery - аналог стандартного TQuery. Компонент предназначен для получения данных на основе SQL-запроса. Этот набор данных не всегда будет редактируемым, зачастую необходимо использовать дополнительный компонент TIBUpdateSQL, чтобы иметь возможность редактировать полученные сведения. Основное свойство - SQL. Основные методы: Open, Close, ExecSQL. Компонент совместим с визуальными компонентами.
TIBDataSet - предназначен для получения и редактирования данных, является потомком стандартного класса TDataSet и полностью совместим со всеми визуальными компонентами. Основные методы: Prepare, Open, Close, Insert, Append, Edit, Delete, Refresh.
TIBStoredProc - предназначен для выполнения хранимых процедур и получения набора данных на основе результатов выполнения процедуры. Получаемый набор данных является нередактируемым. Компонент совместим с визуальными компонентами. Основное свойство - StoredProcName. Основной метод - ЕхесРгос.
TIBUpdateSQL - аналог TUpdateSQL. Используется в паре с TIBQuery и предназначен для создания модифицируемых наборов данных. Основные свойства: DeleteSQL, InsertSQL, ModifySQL и RefreshSQL.
TIBSQL - предназначен для выполнения SQL-запросов. В отличие от TIBQuery или TIBDataSet, TIBSQL не имеет локального буфера для набора данных и несовместим с визуальными компонентами.
TIBDatabaselnfo - позволяет получить системную информацию о некоторых свойствах базы данных, соединения и сервера. Например, UserNames - список пользователей, подключенных к базе данных, PageSize - размер страницы базы данных.
TIBSQLMonitor - предназначен для перехвата и отслеживания всех запросов, которые выполняют приложения, использующие ШХ.
TIBEvents - предназначен для получения пользовательских событий InterBase. Основное свойство - Events. Основные методы: RegisterEvents, UnresisterEvents.
Опции и настройки TpFIBDatabase
TpFIBDatabase содержит ряд специальных свойств, которые управляют режимами работы компонента. Мы уже описывали основные вещи, связанные с подключением к базе данных, однако некоторые особенности TpFIBDatabase остались "за кадром".
Хочется начать с описания механизма поддержки Alias в FIBPIus. Те из вас, кто уже работал с Interbase через Borland Database Engine, наверняка знают про существование такого понятия, как Database Alias, т. е. псевдоним базы данных. С точки зрения BDE Database Alias - это не что иное, как ряд параметров подключения к базе данных, которые хранятся в системном реестре Windows. Программист, который разрабатывает пользовательскую программу, подключающуюся к базе данных, может не указывать реальные параметры подключения, а просто "сослаться" на существующий алиас. Таким образом, если потом, например, хотелось поменять путь к базе данных, то достаточно было изменить информацию в алиасе и перезапустить программу.
Аналогичный механизм реализован и в FIBPIus. Вы можете задать свойство TpFIBDatabase.AliasName и забыть про такие параметры, как путь к базе данных, имя пользователя, character set, SQL Role и SQL Dialect. При запуске программы, если значение свойства AliasName не пустое, TpFIBDatabase будет пытаться получить значения соответствующих свойств из системного реестра. Встает вопрос: а как записать туда первоначальные значения? Для этого существует два способа.
Первый заключается в том, что вы устанавливаете свойство SaveDBParams в True, после чего все необходимые свойства автоматически сохраняются в системном реестре, как только вы подключитесь к базе данных. Фактически это одноразовая операция: установили свойства и имя алиаса, установили SaveDBParams в True, подключились к базе данных - параметры алиаса сохранены. Отключились от базы данных, выставили SaveDBParams в False. Теперь при последующих подключениях значения для свойств буду) брался из системного реестра.
Второй способ - использование утилиты AliasManager, которая написана специально для того, чтобы можно было настраивать значения алиасов на любом клиентском месте без сред Delphi и C++ Builder. Иными словами, вы можете использовать эту утилиту на тех компьютерах, на которые установите свою программу. Мы не будем приводить здесь описание утилиты, поскольку ее использование достаточно очевидно само по себе (рис. 2.29).
Рис 2.29. Внешний вид Alias Manager
Достаточно удобным и полезным также является свойство DesignDBOptions. Если выставить ключ ddoIsDefaultDatabase в True, то у всех компонент (TpFIBDataSet, TpFIBQuery, TpFIBTransaction), которые вы потом положите на форму, автоматически будет заполняться свойство Defaul(Database (или Database). Ключ ddoStoreConnected указывает - сохранять ли значение свойства TpFIBDatabase.Active при сохранении формы или проекта. Дело в том, что активное состояние базы данных зачастую бывает полезно в процессе разработки, когда мы используем визуальные средства FIBPlus: Database Editor, Transaction Editor, SQL Generator и различные свойства. Тем не менее, сохраняя активное подключение (а значит, и автоматически восстанавливая его при загрузке программы!), мы можем получить ошибку в работе приложения, которое может попытаться открыть уже активное подключение. Чтобы избежать подобной накладки, вы можете выставить свойство ddoStoreConnected в False.
Свойство SynchronizeTime предназначено для правильного вычисления default-значений полей. Вы знаете, что в Interbase существуют специальные функции для работы с датами и временем: NOW и CURRENT_TIME (в Firebird). Эти функции часто ИСПОЛЬЗУЮТ при описании полей:
CREATE TABLE NODES_LIST (
ID INTEGER NOT NULL,
INSERTED TIME NOT NULL DEFAULT 'NOW'
);
При вставке записи с пустым значением поля INSERTED сервер автоматически подставит текущее время. Однако существует некоторая особенность при работе клиентской части программы. Как вы понимаете, чтобы работать с таблицей NODES_LIST, нам придется заполнять значения свойств SelectSQL, InsertSQL, DeleteSQL, UpdateSQL и RefreshSQL у некоторого компонента TpFIBDataSet. При вставке TpFIBDataSet проверяет свойства полей таблицы и пытается автоматически заполнить поля новой записи значениями по умолчанию. В нашем случае он должен присвоить полю INSERTED текущее время. Однако поскольку мы можем иметь дело с сетевой системой, то время на сервере может отличаться от времени на клиентской машине. В нашем гипотетическом примере это, возможно, и не играет никакой роли, однако могут быть случаи, когда необходимо подставлять точное "серверное" время. Для этого и используется свойство SynchronizeTime. Если оно выставлено в True, то при подключении к базе данных TpFIBDatabase выясняет "разницу во времени" между сервером и клиентским компьютером, чтобы впоследствии подставлять правильные значения.
Свойство UpperOldNames было введено в FIBPlus на этапе перехода с Interbase 5.x на Interbase 6.x. Как вы знаете, в 3-м SQL Dialect Interbase 6.x позволяет использовать "регистро-чувствительные" имена объектов. В старых версиях Interbase имена INSERTED и inserted являлись одинаковыми, поэтому программисты в своих программах не придерживались точного написания. В частности, можно было писать и следующее:
MainDS.FieldByName('COST').AsFloat :=
ainDS.FieldByNamet'cost').AsFloat * 0,3;
И это работало без ошибок. Однако если просто перенести базу на Interbase 6.x и запустить то же самое приложение, то оно начинало работать с ошибками, поскольку поле COST действительно существовало, а вот поле cost - уже нет. Фактически подобная миграция означала, что нужно было проверять все приложение, чтобы найти подобные подводные камни. FIBPlus позволяет обойтись без подобных мероприятий. Если выставить UpperOldNames в True, то любые идентификаторы, в которых явным образом не используются двойные кавычки, приводятся "внутри" к верхнему регистру, а значит, запись
MainDS.FieldByName('COST').AsFloat :=
ainDS.FieldByName('cost').AsFloat * 0,3;
снова начинает работать без проблем.
Опции и настройки TpFIBDataSet
TpFIBDataSet содержит гораздо больше настроек, которые регулируют его работу. Будет трудно, пожалуй, выбрать наиболее важные, поскольку все они предназначены для совсем разных задач, а поэтому начнем по порядку.
AllowedUpdateKinds. Свойство представляет собой множество из трех элементов: [okModity. uklnsert, ukDelete]. Достаточно очевидно, что, используя это свойство, мы можем разрешать и запрещать выполнение определенных модифицирующих операций TpFTBDataSet. не изменяя при этом свойства InsertSQL. DeleteSQL и UpdateSQL. To есть мы можем получить TpFIBDataSet, который будет считаться "живым", но не будет позволять, например, вставлять новые записи! Это, кстати, одна из стандартных проблем при работе с компонентом TDBGrid, который не позволяет ограничивать изменение данных, — он либо "совсем" редактируемый (а значит, пользователь может изменять поля, удалять записи и вставлять новые), либо "совсем" нередактируемый. При работе с FIBPlus мы можем регулировать это поведение без необходимости писать какие-то специальные обработчики событий. Есть и еще одна особенность в свойстве AllowedUpdateKinds. Как вы уже в курсе, Interbase позволяет регулировать права доступа к объектам базы данных. Таким образом, может возникнуть ситуация, когда конкретный пользователь, работающий с вашей программой, не имеет прав на удаление записей из конкретной таблицы. Писать для каждого пользователя отдельную программу, очевидно, слишком накладно. Однако TpFIBDataSet легко справляется с проблемой, поскольку если при попытке "скомпилировать" конкретный модифицирующий запрос компонент получает от сервера сообщение об ошибке из-за отсутствия прав, то TpFIBDataSet просто запрещает данное действие, убрав соответствующий элемент из свойства AllowedUpdateKinds. Дальнейшие попытки просто, таким образом, пресекаются, а пользователь работает с программой, даже не подозревая об ошибках или отсутствии прав.
Свойство DefaultFormats используется при заполнении свойства DisplayFormat у объектов TField при открытии запроса. Поэтому, если вы хотите автоматически задавать какой-то нужный вам формат представления, например, числовых полей, то вам достаточно указать его в DefaultFormats.NumericDisplayFormat. Правила заполнения масок можно прочитать в описании свойства DisplayFormat у стандартного класса TField.
Свойство Options тоже управляет режимами работы TpFIBDataSet, причем надо иметь в виду, что эти опции управляют поведением TpFIBDataSet уже после открытия запроса или в момент редактирования данных:
poTrimCharFields - среди разработчиков идут постоянные споры, должны ли компоненты для работы с Interbase "обрезать" конечные пробелы у строковых полей или нет. С одной стороны, дополнение пробелами - это описанная техническая особенность Interbase, а с другой стороны - это не всегда удобно для пользователя. Нет нужды спорить, если можно отрегулировать этот процесс в отдельно взятом приложении (и даже в отдельно взятом запросе) Включив ключ PoTrimCharFields, вы можете быть уверены, что пробелов в конце строковых полей не будет.
poRep-eshAperPost позволяет вам отключить выполнение "обновляющего" запроса после редактирования записи. Как уже было сказано, после операции Post TpFIBDataSet автоматически выполняет запрос из свойства RefreshSQL, чтобы получить актуальные значения всех полей измененной записи, поскольку они могли быть изменены при помощи триггеров. Это дополнительный запрос, и если вы считаете, что в нем нет никакой нужды (например, вы точно уверены, что никакие триггеры не изменяют записи в таблице), то вы можете отключить этот режим.
При включенной опции poRefreshDeletedRecord если в результате выполнения RefreshSQL запрос ничего не вернул (в частности, это может произойти, если запись была удалена другим пользователем), то TpFIBDataSet также удалит ее из внутреннего буфера.
poStartTransaction отвечает за автоматический запуск транзакции перед открытием запроса, если транзакция еще не была активна. Если вы предпочитаете вызывать метод StartTransaction вручную, то можете отключить данную опцию.
poAutoFormatFields разрешает или запрещает автоматическое форматирование полей на основе форматов, заданных в свойстве DefaultFormats.
poProtectEdit руководит режимом "защищенного" редактирования. Этот режим иногда полезен, если вы хотите избежать коллизий при редактировании одной и той же записи разными пользователями. Если активизировать режим, то, как только вы начинаете редактировать запись (но до вызова метода Post), на сервер отправляется так называемый "холостой" update вида:
UPDATE TABLE
SET FIELD1 = FIELD1,
FIELD2= FIELD2, ...
To есть запрос, который формально является редактированием записи, а фактически не изменяет значения полей. Тем не менее сервер считает, что изменения произошли, а значит, пользователь, который первым начал редактирование, имеет преимущество перед всеми последующими. Фактически это эмуляция режима блокировок на уровне записей. Проблема, однако, состоит в том, что в Interbase не существует возможности отменить UPDATE, не отменив транзакции целиком. Поэтому даже если пользователь начал редактирование записи, а потом отказался и метод Post так и не был вызван, то запись все равно будет считаться измененной до конца транзакции. Кроме того, данный режим практически совершенно бесполезен, если вы используете режим работы в контексте двух транзакций, как это было описано выше, поскольку "блокировка" действует только до конца изменяющей транзакции.
Опция poKeepSorting нужна, если вы используете методы локальной сортировки DoSort и DoSortEx. Эти методы выполняют сортировку записей внутри локального буфера (без запроса на сервер). При изменении значений полей возможна ситуация, что измененная запись должна быть помещена в другое место (если изменилось, например, значение поля, по которому записи отсортированы). При активной опции poKeepSorting, после изменения записи, весь буфер автоматически сортируется и запись "встает" на нужное место.
poPersistentSorting - при активной опции, если вы вызывали методы DoSort или DoSortEx, то после переоткрытия запроса результат будет автоматически отсортирован вызовом DoSort с теми же параметрами.
Опция poAllowChangeSQLs блокирует или разрешает изменение свойств InsertSQL, DeleteSQL, UpdateSQL и RefreshSQL при открытом запросе.
Свойство PrepareOptions, в отличие от Options, позволяет задать некоторые особенности поведения TpFEBDataSet до открытия запроса:
pfSetRequiredFields - если опция активна, то для полей, которые в базе данных были описаны как NOT NULL, свойство TField.Required будет выставлено в True Если пользователь попробует не задать значение для таких полей, например, в TDBGnd, то на экран будет выведено стандартное предупреждение
При включенной опции pfSetReadOnlyFielcls для полей, которые описаны в базе как вычислимые (а значит, не изменяемые пользователем), свойство TField ReadOnly будет выставлено в True Это позволит избежать попыток изменения значений таких полей пользователем.
pflmportDefaultValues - данная опция включает и выключает режим, при котором TpFIBDataSet будет автоматически заполнять поля их значениями по умолчанию при вставке новой записи.
Опция psUseBooleanFields включает или выключает режим эмуляции Boolean-полей Вы знаете, что Interbase не поддерживает специальный тип для логических значений и разработчики вынуждены так или иначе заменять его своим пользовательским типом. Однако даже пользовательские типы не дают равноценной замены Boolean-типу, поскольку визуальные компоненты все равно видят такие поля либо как числовые, либо как строковые в зависимости от описания Таким образом, пропадает возможность использования каких-то специальных возможностей отображения логических полей визуальными компонентами (например, многие сторонние компоненты наподобие TDBGrid отображают логические поля галочками). FIBPlus позволяет эмулировать Boolean-поля гораздо более эффективно. Необходимо описать в базе данных домен вида:
CREATE DOMAIN T_BOOLEAN
AS INTEGER DEFAULT 0
NOT NULL CHECK (VALUE IN (0,1))
Поле должно быть целочисленным и содержать в названии слово "boolean". После этого все поля, которые вы создадите с использованием данного домена, будут "распознаваться" в FIBPlus как Boolean-поля, т. е. для них будут создаваться экземпляры класса TFIBBooleanField, который является прямым потомком стандартного TBooIeanField, значит, любой визуальный компонент будет работать с такими полями как с настоящими Boolean!
psSQL!NT64ToBCD - опция заставляет TpFIBDataSet создавать экземпляры TBCDField для полей INT64 с любым масштабом (в SQL Dialect 3), что гарантирует точность вычислений для любых полей INT64.
psApplyRepositary - опция включает или выключает режим использования FIBPlus Repository. Эта особенность FIBPlus требует отдельного разговора, и мы вернемся к ее рассмотрению позже в отдельном параграфе.
psGetOrderlnfo - при включенном режиме, FIBPlus анализирует запрос перед выполнением и автоматически заполняет структуру SortFields данными о полях, по которым происходит сортировка в запросе. Впоследствии это может быть использовано в методах локальной сортировки DoSort и DoSortEx
Опция psAskRecordCount предназначена для получения информации о количестве записей, которые должен вернуть запрос, до выполнения, собственно, запроса Дело в том, что фактически, значение свойства TpFIBDataSet RecoidCount показывает лишь количество записей, которые мы уже получили с сервера Это число может отличаться от полного количества записей, поскольку если мы не вызывали метод FetchAll, то сервер "отдает" нам записи по мере необходимости (при вызове метода Next). Иногда бывает полезно узнать точное количество заранее В этом случае нужно включить опцию psAskRecordCount. Однако необходимо учитывать, что данная опция имеет ряд ограничений. Поскольку единственным способом узнать количество записей в запросе заранее является выполнение другого запроса вида SELECT COUNT (*) с теми же условиями, что и в основном запросе, то для некоторых запросов мы выполнить такую операцию не можем Например, если мы имеем запрос
SELECT ID FROM TABLE1
UNION
SELECT ID FROM TABLE2
то запрос SELECT COUNT(*) .. попросту теряет смысл, поскольку результат будет ложным по определению В общем случае опция psAskRecordCount не работает с запросами, которые содержат команды UNION, ORDER и DISTINCT.
Особенности TIBTable, TIBQuery и TIBStoredProc
Фактически, компонент TIBCustomDataSet имеет всю необходимую функциональность для получения базы данных InterBase и поддерживает возможность редактирования этой информациии с помощью визуальных db-aware- компонентов
Для выборки данных, их изменения, удаления и вставки в TIBCustomDataSet используется набор свойств, представляющих собой SQL-запросы для манипулирования данными, - это SelectSQL, DeleteSQL, InsertSQL и ModifySQL.
Отдечьно следует сказать о RefieshSQL Этот запрос не используется для модификации записи, но является очень полезным для получения значений полей, которые были изменены триггерами базы данных и конкурирующими транзакциями
В свойстве SelectSQL указывается запрос на выборку данных (SELECT... FROM ..), которые будут доступны для просмотра и, в зависимости от содержимого остальных запросов, для редактирования, удаления и т д.
В свойствах DeleteSQL, InsertSQL и ModifySQL указываются соответствующие запросы, которые будут вызываться автоматически самим компонентом при вызове операций Delete, Insert и Edit для удаления, вставки и редактирования записей.
Фактически все, что нужно сделать программисту, - это написать нужные запросы, выполняющие нужные операции над записями. Далее мы более подробно рассмотрим потомков TIBCustomDataSet.
Отчеты вида master-detail
Теперь мы можем приступить к построению отчета более сложной структуры, хотя фактически это реализуется так же просто, как и предыдущий вид отчета. Сначала добавим на нашу форму еще один компонент frDBDataSet2: TfrDBDataSet - и зададим его свойство DataSource равным GoodsSource. Теперь необходимо добавить две полосы (bands): Detail Header (заголовки детализованных данных) и Detail Data (сами данные). На Detail Data мы разместим два объекта типа TfrMemoView. В первом мы будем выводить названия товаров, а во втором - цену каждого товара (рис. 2.38):
Рис 2.38. Шаблон отчета для связи мастер-деталь
Очевидно, что мы должны указать источником данных для Detail Data компонент frDBDataSet2. Отчет готов. Сохраним его в файл 'price_list.frf и изменим немного обработчик клавиши "Печать":
procedure
TMainForm.PrintBClick(Sender: TObiect);
begin
GoodsDataSet.DetailConditions :=
GoodsDataSet.DetailConditions [dcWaitEndMasterScroll];
frReport.LoadFromFile('price.f rf');
frReport.PrepareReport ;
frReport.ShowPreparedReport;
GoodsDataSet.DetailConditions :=
GoodsDataSet DetailConditions + [dcWaitEndMasterScroll];
end,
Важный момент касается изменения DetailConditions. Как уже было сказано, ключ dcWaitEndMasteiScioll позволяет избегать лишних запросов при навигации по master-запросу. Однако в ел) чае с распечаткой полного отчета это может привести к тому, что для каждой категории товара мы будем иметь одни и те же наименования, поскольку GoodsDataSet не будет переоткрывать запрос, пока FastReport будет получать данные из CategonesDataSet Чтобы избежать такой ошибки, мы отключаем оптимизацию master-detail на период подготовки отчета и включаем ее вновь после того, как отчет уже готов
Теперь при запуске приложения мы можем легко распечатать весь наш прайс-лист (рис 2.39.)
Рис 2.39. Внешний вид отчета вида мастер-деталь
При желании мы можем выделить цветом или курсивом "горячие" (к примеру, самые дешевые) позиции прайса. Для этого в дизайнере выберем TfrMemoView, затем воспользуемся Objectlnspector и установим свойство Highlight. Для этого в поле "Condition" появившегося окна введем условие Value<0 и выберем способ выделения. В нашем примере все позиции прайса с ценой менее 1000 будут выделены ярко-зеленым цветом (рис. 2.40).
Рис 2.40. Диалог параметров условного форматирования
Поддержка array-полей. Пример использования TpFIBUpdateObject и TDataSetContainer
InterBase с самых ранних версий позволял описывать в таблицах многомерные поля-массивы, делая хранение специализированных данных максимально удобным. Вы наверняка согласитесь, что матриц) проще всего хранить и обрабатывать в виде матрицы, а не раскладывать ее по отдельным полям и даже таблицам из-за ограничений реляционной модели Тем не менее поскольку array- поля не поддерживаются стандартом SQL, то и работа с такими полями на уровне SQL-запросов крайне затруднена. Фактически вы можете использовать массивы только поэлементно и только в операциях чтения Чтобы изменить значения array-поля, необходимо использовать специальные команды InterBase API. FIBPlus позволяет обойтись без подобных сложностей, взяв на себя всю рутину, связанную с array-полями
Мы продемонстрируем, как работать с array-полями при помощи FIBPlus на примере DemoArray5, входящем в стандартную поставку FIBPlus. Пример демонстрирует два варианта использования array-полей Первый способ позволяет редактировать array-поле при помощи специальных методов ArrayFieldValue и SetAiiayValue и работать с таким полем как с единой структурой (рис 2 6П
Рис 2.61. Внешний вид формы примера DemoArrayS Первый вариант использования array—полей
Рассмотрим запросы, заданные в соответствующих свойствах ArrayDataSet:
SeleetSQL
SELECT
JOB JOB_CODE,
JOB.JOB_GRADE,
JOB.JOB_COUNTRY,
JOB.JOB_TITLE,
JOB MIN_SALARY,
JOB.MAX_SALARY,
JOB.JOB_REQUIREMENT,
JOB.LANGUAGE_REQ
FROM
JOB JOB
ORDER BY 1,2,3
UpdateSQL:
UPDATE JOB SET
JOB_CODE = ?JOB_CODE,
JOB_GRADE = ?JOB_GRADE,
JOB_COUNTRY = ?JOB_COUNTRY,
JOB_TITLE = ?JOB_TITLE,
MIN_SALARY = ?MIN_SALARY,
MAX_SALARY = ?MAX_SALARY,
JOB_REQUIREMENT = ?JOB_REQUIREMENT,
JOB.LANGUAGE_REQ= ?LANGUAGE_REQ WHERE
JOB_CODE = ?OLD_JOB_CODE
and JOB_GRADE = ?OLD_JOB_GRADE
and JOB_COUNTRY = ?OLD_JOB_COUNTRY
InsertSQL
INSERT INTO JOB(
JOB_CODE,
JOB_GRADE,
JOB_COUNTRY,
JOB_TITLE,
MIN_SALARY,
MAX_SALARY,
JOB_REQUIREMENT,
JOB.LANGUAGE_REQ
)
VALUES(
?JOB_CODE,
?JOB_GRADE,
?JOB_COUNTRY,
?JOB_TITLE,
?MIN_SALARY,
?MAX_SALARY,
?JOB_REQUIREMENT,
?LANGUAGE_REQ
)
DeleteSQL:
DELETE FROM JOB
WHERE
J03_CODE = ? OLD_JOB_CODE
and JOB_GRADE = ?OLD_JOB_GRADE
and JOB_COUNTRY = ?OLD_JOB_COUNTRY
RefreshSQL:
SELECT
JOB.JOB_CODE,
JOB.JOB_GRADE,
JOB.JOB_COUNTRY,
JOB.JOB_TITLE,
JOB.MIN_SALARY,
JOB.MAX_SALARY,
JOB.JOB_REQUIREMENT,
JOB.LANGUAGE_REQ
FROM
JOB JOB
WHERE
(
JOB.JOB_CODE = ?OLD_JOB_CODE
and JOB.JOB_GRADE = ?OLD_JOB_GRADE
and JOB.JOB_COUNTRY = ?OLD_JOB_COUNTRY
)
Поле LANGUAGE_REQ является массивом (LANGUAGE_REQ VARCHAR(15) [1:5]) и, как видно из запросов, обрабатывается целиком, а не поэлементно. С одной стороны это удобно, но не позволяет использовать для редактирования таких полей специализированные визуальные компоненты типа TDBGrid. Если мы используем array-поля для хранения значительных массивов данных, мы в любом случае будем использовать "ручную" обработку данных, не прибегая к помощи визуальных компонент. Однако для наглядности примера мы позволим редактировать элементы массива в компонентах TEdit.
Фактически нам понадобится написать только два основных обработчика для событий: BeforePost и OnPostError
procedure TForml.ArrayDataSetBeforePost(DataSet: TDataSet);
begin
with ArrayDataSet do begin
SetArrayValue(FieldByName('LANGUAGE_REQ'),
VarArrayOf([
Editl.Text,
Edit2.Text,
Edit3.Text,
Edit4.Text,
Edits.Text
]) ) ;
end;
end;
procedure TForml.ArrayDataSetPostError(DataSet: TDataSet;
E: EDatabaseError; var Action: TDataAction);
begin
Action := daAbort;
MessageDlg('Error!', mtError, [mbOk], 0);
ArrayDataSet.Refresh;
end;
Метод SetArrayValue позволяет задать все элементы поля в виде массива. Важным моментом является обработчик ошибки ArrayDataSetPostError В случае неудачной операции Update или Insert необходимо восстанавливать внутренний идентификатор массива у редактируемой записи. Это правило диктуется функциями InterBase API, и мы должны их придерживаться. Для восстановления идентификатора необходимо получить значения полей текущей записи заново, что и делается при помощи явного вызова метода Refresh.
Для автоматического заполнения визуальных компонентов значениями элементов массива мы можем написать обработчик события AfterScroll:
procedure TForml.ArrayDataSetAfterScroll(DataSet: TDataSet);
var v: Variant;
begin
with ArrayDataSet do try
FInShowArrays := true;
v := ArrayFieldValue(FieldByName('LANGUAGE_REQ'));
Editl.Text := VarToStr(v[l]);
Edit2.Text := VarToStr(v[2]);
Edit3.Text := VarToStr(v[3]);
Edit4.Text := VarToStr(v[4]);
EditS.Text := VarToStr(v[5]);
finally
FInShowArrays:=false;
end;
end;
Флаг FInShowArrays используется в примере для того, чтобы не включать режим редактирования записи при обычной навигации.
Рекомендуется иметь под руками полный текст примера, который доступен на сайте http://www.fibplus.net. В книге мы указываем только те части примера, которые имеют непосредственное и наибольшее значение для работ с array-полями. Однако без полного текста некоторые части исходного текста могут показаться не до конца наглядными.
Данный способ работы с array-полями нельзя применять в режиме CachedUpdates.
Второй способ работы с array-полями позволяет использовать их в "живых" запросах и редактировать при помощи стандартных визуальных компонентов (рис. 2.62).
Рассмотрим запросы, указанные в свойствах ArrayDataSet:
SelectSQL:
SELECT
JOB.JOB_CODE,
JOB.JOB_GRADE,
JOB.JOB_COUNTRY,
JOB.JOB_TITLE,
JOB.LANGUAGE_REQ[1] LQ1,
JOB.LANGUAGE_REQ[2] LQ2
FROM
JOB JOB
ORDER BY 1,2,3
Рис 2.62. Внешний вид формы примера DemoArrayS. Второй вариант использования array-полей
UpdateSQL:
UPDATE JOB SET
JOB_TITLE = -?JOB_TITLE,
JOB JOB_GRADE=?JOB_GRADE,
JOB.JOB_COUNTRY=?JOB_COUNTRY,
LANGUAGE_REQ = ''LQ
WHERE
JOB_CODE = ?OLD_JOB_CODE
and JOB_GRADE = ?OLD_JOB_GRADE
and JOB_COUNTRY = ?OLD_JOB_COUNTRY
InsertSQL:
INSERT INTO JOB(
JOB_CODE,
JOB_GRADE,
JOB_COUNTRY,
JOB_TITLE,
LANGUAGE_REQ
)
VALUES(
?JOB_CODE,
?JOB_GRADE,
?JOB_COUNTRY,
?JOB_TITLE,
?LQ
)
DeleteSQL:
DELETE FROM JOB
WHERE
JOB_CODE = ?OLD_JOB_CODE
and JOB_GRADE = ?OLD_JOB_GRADE
and JOB_COUNTRY = ?OLD_JOB_COUNTRY
RefieshSQL:
SELECT
JOB.JOB_CODE,
JOB.JOB_GRADE,
JOB.JOB_COUNTRY,
JOB.JOB_TITLE,
JOB.LANGUAGE_REQ[1] LQ1,
JOB.LANGUAGE_REQ[2] LQ2
FROM
JOB JOB
WHERE
(
JOB.JOB_CODE = ?OLD_JOB_CODE
and JOB. JOB_GRADE = ?OLD_JOB_GRADE
and JOB.JOB_COUNTRY = ?OLD_JOB_COUNTRY
)
На этот раз мы выбираем только два элемента из нашего поля-массива. Обратите внимание' несмотря на то что в выбирающем запросе мы явным образом выделяем два элемента массива, а в модифицирующих запросах мы обновляем поле целиком На самом деле, это, конечно, не совсем так, однако данный синтаксис наиболее удобен и близок к естественному SQL-запросу несмотря на то что во внутренней реализации FIBPlus использует специальные функции работы с массивами Обратим внимание на компонент QryAirField TpFIBUpdateObject. Именно он позволит нам правильно сформировать значение параметра "LQ" в модифицирующих запросах Разумеется, для этой цели вполне бы подошел и простой TpFIBQuery, однако удобство TpFIBUpdateObject заключается в первую очередь в том, что он выполняет запрос автоматически и сам подставляет туда нужные значения параметров в зависимости от значений TpFIBDataSet. Вот запрос, который выполняет QryArrField SELECT
JOB LANGUAGE_REQ,
JOB JOB_CODE
FROM
JOB JOB
WHERE
JOB JOB_CODE=?OLD_JOB_CODE and
JOB.JOB_GRADE=?OLD_JOB_GRADE and
JOB.JOB_COUNTRY=?OLD_JOB_COUNTRY
Обратим внимание на свойства QryArrField (рис 2 63)
Рис 2.63. Свойство компонента QryArrField
Обработчик QiyAnField AtteiExecute
procedure TForm2 QryArrFieldAfterExecute(Sender: TObject);
var v Variant,
begin
v = QryArrField Fields[0] GetArrayValues,
with ArrayDataSet do begin
v[l] = FieldByName('LQ1') AsString,
v[2] = FieldByName( LQ2 ) AsString,
QryArrField Fields[0] SetArrayValue(v);
QUpdate Params ByName[ LQ ] AsQuad :=
QryArrField.Fields[0] AsQuad;
end;
QryArrField Close;
end;
Теперь все становится совершенно очевидным Поскотьку свойство QiyAnField KindUpdate равно ukModify, то QiyArrField выполняет запрос при изменении записи в AnayDataSet а поскольку свойство QiyArrField ExecuteOider равно eoBeforeDefault, то запрос (QiyArrField SQL) выполняется до того, как AirayDataSet выполнит свой собственный UpdateSQL В обработчике QryArrField AfterExecute мы всего лишь получаем заново все текущие элементы массива из базы данных, подменяем два из них новыми значениями, которые указал пользователь, и задаем значение параметра для ArrayDataSet.UpdateSQL Это означает что при выполнении ArrayDataSet.UpdateSQL формально будут обновлены все пять элементов массива но фактически изменены значения тотько двух элементов, которые изменил пользователь в TDBGrid.
Как видите работа с массивами достаточно проста поскотьку все основные сложности решают компоненты FIBPlus Хотелось бы также рассмотреть еще один специализированный компонент, входящий в FIBPlus Пример DemoArray демонстрирует работу с TDataSetContamei, использованным для синхронизации значений двух TpFIBDataSet, редактирующих наше апау-поле (рис 2 64)
Рис 2.64. Использование TDatabetContamer
Компонент DataSetContamerl помещен вместе с Database и Transaction на DataModule в нашем приложении Оба компонента AnayDataSet из разных форм нашего приложения ссылаются на DataSetContamerl при помощи свойства Contamei (рис 2 65)
Рис 2.65. Подключение компонентов TpFIBDataSet к DataSetContamerl
Компонент TDataSetContamei позволяет централизованно обрабатывать события от разных компонентов TpFIBDataSet, а также (расширяя, таким образом, список стандартных событий) посылать им сообщения, при получении которых они могут производить какие-то дополнительные действия. В нашем примере DataSetContainerl имеет обработчики двух событий OnDataSetEvent и OnUserEvent
procedure TDataModule2.DataSetsContainerlDataSetEvent(DataSet:
TDataSet;
Event: TKindDataSetEvent);
var Info: string;
begin
if Event = deAfterPost then
if DataSet.Owner.Name = 'Forml' then
DataSetsContainerl.NotifyDataSets(DataSet,
'Form2.ArrayDataSet', 'JOB_TABLE_CHANGED', Info)
else
if DataSet.Owner.Name = 'Form2' then
DataSetsContainerl.NotifyDataSets(DataSet,
'Form1.ArrayDataSet', 'JOB_TABLE_CHANGED', Info);
end;
procedure TDataModule2.DataSetsContainerlUserEvent(Sender:
TObject;
Receiver: TDataSet; const EventName: String; var Info:
String) ;
begin
if EventName = 'JOB_TABLE_CHANGED' then begin
with TpFIBDataSet(Sender) do
if (not CachedUpdates) and
(not TpFIBDataSet(Receiver).CachedUpdates) then
if
TpFIBDataSet(Receiver).Locate('JOB_CODE;JOB_GRADE;JOB_COUNTRY', varArrayOf([
FieldByNamet'JOB_CODE').AsString,
FieldByName('JOB_GRADE').AsString,
FieldByName('JOB_COUNTRY').AsString
]), []) then TpFIBDataSet(Receiver) Refresh
end;
end;
Смысл действий сводится к следующему: после изменения записи в одном из наших компонентов ArrayDataSet происходит событие AfterPost. Поскольку DataSetContainerl перехватывает все события у подчиненных компонентов, то срабатывает обработчик OnDataSetEvent. Параметр Event равен deAfterPost, а параметр DataSet ссылается на тот компонент, в котором произошло изменение записи. При помощи вызова метода NotifyDataSets DataSetContainerl посылает сообщение оставшемуся компоненту ArrayDataSet о том, что произошло изменение записи. Поскольку оба компонента на самом деле редактируют одну и ту же таблицу, то желательно синхронизировать изменения. Синхронизация происходит в обработчике события OnUserEvent, то есть при получении "извещения" об изменении какого-либо из ArrayDataSet.
Если получено сообщение "JOB_TABLE_CHANGED" и ни в одном из наших двух ArrayDataSet не включен режим CachedUpdates (в этом случае Refresh просто ничего не даст), то мы позиционируемся на соответствующую запись и вызываем для нее метод Refresh, обновив, таким образом, запись в одном ArrayDataSet после того, как она была изменена в другом ArrayDataSet.
Данная технология является совершенно уникальной: использование DataSetContainer позволяет делать чрезвычайно гибкие и в то же время прозрачные схемы обработки и синхронизации данных в нескольких компонентах TpFIBDataSet.
Подключение к базе данных
Очевидно, что прежде чем начать работать с базой данных, надо к ней подключиться. Специально для этого в состав IBX включен компонент TIBDatabase.
Для наших примеров в этой главе мы будем использовать базу данных Employee.gdb, которая поставляtnся вместе с InterBase.
Поместите TIBDatabase на форму и вызовите контекстное меню (рис. 2.2).
Рис. 2.2. Вызов редактора IBDatabase
Из рисунка видно, что у TIBDatabase существует специальный редактор, который позволяет вам настраивать определенные параметры компонента во время разработки приложения (рис. 2.3).
Рис. 2.3. Редактор TIB Database
В частности, необходимо указать путь к базе данных в разделе Connection. Путь включает в себя имя сервера и локальный путь к файлу базы данных на сервере. В случае, если сервер локальный, то достаточно указать только путь к файлу базы данных.
Немного подробнее относительно использования удаленного сервера. Предположим, что InterBase установлен у вас в сети на компьютере с сетевым именем SERV_IB и доступен по протоколу TCP/IP. Пусть база данных находится на сервере на диске Е: в файле MY_DB.GDB. В данной ситуации в редакторе компонента вам надо будет указать тип подключения Remote, имя сервера SERV_1B, а путь к базе данных оставить локальным относительно сервера, т. е. , ЕЛ MY_DB.GDB. Это важный момент! Вы указываете серверу путь к локальному файлу базы на сервере, а не указываете вашей программе сетевой путь к базе данных. В сущности, именно об этом говорится в главе "Создаем базу данных" в разделе "Строка соединения", а здесь мы лишь хотим еще раз подчеркнуть, что данный редактор создает точно такую же строку соединения, которую вы вводите вручную, например, при использовании инструментов администратора и разработчика InterBase.
Вы можете протестировать параметры подключения не выходя из диалога при помощи кнопки Test. Если все указано правильно, то вы увидите сообщение Successful connection.
Подключение к базе данных, выполнение простых запросов
Рассмотрим с самого начала создание приложения, при помощи которого мы сможем редактировать прайс-лист. Необходимо поместить на форме основной компонент, который позволяет подключаться к базе данных InterBase (TpFIBDatabase) и вызвать редактор этого компонента (рис. 2.14 и 2.15).
Рис 2.14. Вызов редактора TpFIBDataBase
Рис 2.15. Bug редактора компонента TpFIBDataBase
Для подключения к базе как минимум необходимо указать путь (в данном примере это путь к локальному файлу), имя пользователя и пароль. Вы можете проверить правильность заданных параметров, нажав на кнопку Test. Мы также можем задать параметры подключения к базе в run-time, получив путь к базе данных из ini-файла:
procedure TMainForm.FormCreate(Sender: TObject);
begin
with TiniFile.Create('ib_price.ini') do begin
pFIBDatabasel.DBName := ReadString('Options', 'DBPath',
'C:\IBPRICE.GDB');
Free ;
end;
pFIBDatabasel.Open;
end;
Компонент TpFIBDatabase можно также использовать для выполнения запросов к базе данных, которые не возвращают в результате набора данных. Для этого существуют такие методы:
function Execute(const SQL: string): boolean;
function QueryValue(const aSQL: string;
FieldNo:integer):Variant;
function QueryValueAsStr (const aSQL: string,-
FieldNo:integer): String;
Например, мы можем выяснить количество категорий товаров, выполнив простой запрос:
SnowMessage(pFIBDatabasel.QueryValueAsStr('select count("Id")
from "Categories"', 0));
Правильный способ использования auto-increment полей в FIBPIus
В текущем состоянии наш запрос уже является редактируемым, мы можем вставлять новые записи, удалять записи существующие, а также редактировать значения полей Тем не менее пользователь должен самостоятельно указывать значение ключевого поля "Id", чтобы каждая запись была уникальной. Разумеется, мы можем переложить заботу о генерации уникальных значений на базу данных, написав соответствующий триггер, который при вставке новой записи будет автоматически получать новое уникальное значение из некоторого 1енерагора. Такой способ гарантирует уникальность значений, но не гарантирует правильность работы клиентского приложения.
Особенность использования генераторов при написании корректно работающих приложений на FIBPlus состоит в том, что мы должны получать новое значение генератора в приложении до того, как выполним запрос на вставку записи. Зачем это нужно? Дело в том, что, как уже было сказано, после выполнения любого модифицирующего запроса (кроме удаления) CategoriesDataSet автоматически выполняет запрос из RefreshSQL, подставляя в качестве условия текущие значения параметров. В нашем случае для подстановки надо использовать значение первичного ключа (поле "Id"). Если мы не получим его заранее, а будем генерировать его, используя триггер, то мы не сможем подставить значение параметра : "OLD_Id" в запрос RefreshSQL, а значит, не сможем перечитать измененную запись. Таким образом, если какие-то поля записи были изменены триггерами базы данных, то мы не увидим этих изменений, пока не переоткроем весь запрос целиком Если же мы сначала получим новое значение генератора, а потом вставим это значение наравне с остальными параметрами, то затем мы сможем использовать это же значение, чтобы "перечитать" текущую запись, и будем "в курсе" актуальных значений полей без излишних переоткрываний!
TpFIBDataSet позволяет автоматически получать и вставлять значения первичного ключа, используя генератор. Для этого нам необходимо заполнить некоторые дополнительные ключи в свойстве AutoUpdateOptions (рис. 2.24).
Нужно указать название генератора Categories_Id_GEN. Свойство WhenGetGenID может принимать три возможных значения:
wgOnNewRecord - получать значение генератора сразу после подготовки буфера для новой записи;
wgBeforePost - получать значение генератора непосредственно перед отправкой новой записи на сервер;
wgNever- не использовать механизм генерации ключевых значений.
В нашем примере мы укажем значение wgOnNewRecord, чтобы сразу видеть в CategoriesGrid те значения поля "Id", которые будут получены с сервера. Теперь мы можем запустить наше приложение и отредактировать какие-либо существующие записи и даже вставить новые записи (рис. 2.25).
Рис 2.24. Использование AutoUpdateOptions для генерации уникальных значений первичного ключа
Рис 2.25. Внешний вид "живого" запроса
Из рисунка видно, что было автоматически получено значение для поля "Id" равное 66
Preferences
Пункт Preferences позволяет настроить параметры основных компонентов по умолчанию (рис. 2.53).
На первой странице диалога вы можете задать значения по умолчанию для свойств Options, PrepareOptions и DetailsConditions для всех компонентов класса TpFIBDataSet. Вы можете задать определенные ключи для этих свойств. Например, если вы включите флажок SetRequiredFields то, когда вы положите новый компонент TpFIBDataSet на вашу форму, ее свойство PrepareOptions будет содержать ключ pfSetRequiredFields. Наиболее важным является тот факт, что умолчания, заданные в FIBPIus Tools Preferences, действуют во всех приложениях, которые вы будете создавать. Однако необходимо иметь в виду, что это только первоначальные умолчания. То есть если после помещения компонента на форму вы измените свойства, то это никак не коснется Preferences. Также изменение Preferences не коснется тех компонент значения свойств которых уже были заданы.
Рис. 2.53. Диалог настройки опций TpFIBDataSet в design-time.
Обратите внимание на поля "Prefix Generator name" и "Suffix Generator name". Задав их значения, вы сможете регулировать формирование имен для названий генераторов в свойстве AutoUpdateOptions у TpFIBDataSet. Имя генератора в AutoUpdateOptions генерируется из названия таблицы (UpdateTable), префикса и суффикса.
Следующие страницы диалога позволяют настраивать ключевые свойства компонентов TpFIBDataBase, TpFIBTransaction и TpFIBQuery.
В частности, если вы всегда работаете с новыми версиями InterBase, т. е. С версиями 6 и более (а также Firebird), то мы рекомендуем вам задать значение SQL Dialect на закладке TpFIBDatabase равным 3, чтобы каждый раз не переключать это свойство вручную.
Программное редактирование данных
Как показал некоторый опыт в поддержке пользователей, программисты, впервые применяющие IBX и аналогичные компоненты, не совсем понимают каким образом можно использовать TIBDataSet для того, чтобы управлять данными программно, а не просто давать пользователю возможность вносить какието исправления.
Например, периодически возникает вопрос: "А как мне автоматически вставить новую запись в IBDataSet? Может быть, стоит разместить рядом отдельный компонент IBSQL, в котором написать запрос INSERT, выполнить его, а потом переоткрыть IBDataSet? Или, может быть, можно синхронизировать новую запись в IBSQL и существующие записи в IBDataSet? Существуют ли методы для прямого редактирования локального буфера записей в IBDataSet?"
Подобные "технологические" решения можно придумывать очень долго: поскольку фантазия разработчиков практически неистощима, мы можем найти выход из любой ситуации и обойти любое ограничение существующей технологии. Однако в данном случае решения "проблемы" проистекают от простого непонимания принципов работы IBDataSet. Поверьте, все гораздо проще.
В самом начале главы сказано, что TIBDataSet порожден классом TDataSet, а значит, наследует основные принципы его работы. У TIBDataSet как наследника TDataSet существует три основных метода для изменения данных: Delete, Insert (Append) и Edit.
Предположим, что мы хотим вставить новую запись в наш IBDataSetl по нажатии кнопки:
procedure TForml.ButtonlClick(Sender: TObject);
begin
with IBDataSetl do begin
Insert;
FieldByName('EMP_NO').Aslnteger := 147;
FieldByName('DEPT_NO').Aslnteger := 600;
FieldByName('JOB_CODE').AsString := 'VP';
FieldByName('JOB_GRADE') .Aslnteger : = 2 ;
FieldByName('SALARY').Aslnteger := 105900;
FieldByName('HIRE_DATE').AsDateTime := Now;
FieldByName('JOB_COUNTRY').AsString := 'USA';
FieldByName('FIRST_NAME').AsString := 'Иван';
FieldByName('LAST_NAME').AsString := 'Иванов';
Post;
end;
end;
Теперь поясним, как это работает. После того как мы вызываем метод Insert, IBDataSetl формирует пустой буфер для нашей (пока еще не введенной) записи. Далее мы задаем значения нужных полей при помощи вызовов метода FieldByName и заканчиваем (точнее, подтверждаем) редактирование вызовом метода Post. В этот момент IBDataSetl выполняет запрос, прописанный в свойстве InsertSQL, подставив вместо параметров те значения полей, которые мы задали.
Если запрос выполнился успешно, то IBDataSetl автоматически выполняет RefreshSQL для обновления только что вставленной записи - для проверки изменений, внесенных на стороне базы данных.
Аналогичным образом мы можем редактировать записи. Например, мы можем модифицировать все записи в нашем запросе:
procedure TForml.ButtonlClick(Sender: TObject);
begin
with IBDataSetl do begin
First;
while not Eof do begin
Edit;
FieldByName('LAST_NAME').AsString :=
trim(FieldByName('LAST_NAME').AsString) + ', esquire;
Post;
Next ;
end;
end;
end;
Принцип тот же самый, что и при вставке записей. Мы вызываем метод Edit, подготавливая буфер текущей записи для редактирования, потом меняем значения поля при помощи FieldByName, а потом заканчиваем редактирование, вызвав метод Post. В результате IBDataSetl подставляет значения полей записи в ModifySQL и выполняет запрос.
Оговоримся, что в реальной практике подобная обработка большого множества записей не является хорошим решением. Гораздо легче было бы выполнить одну команду UPDATE, которая добавила бы строку ', esquire' ко всем записям таблицы. Пример выше дан только для демонстрации метода Edit.
Как видно из примеров выше, нет никакой нужды ни в каких дополнительных компонентах, синхронизации о прочих непонятных "телодвижениях", если мы хотим редактировать данные в IBDataSet программно.
Простой отчет
Не претендуя на демонстрацию всех возможностей FastReport, поскольку этот пакет предоставляет очень мощные и гибкие возможности для построения отчетов, мы создадим отчет, который распечатает наш price-лист.
Идеология FastReport позволяет включать "внутрь" отчетов совершенно независимые источники данных (и даже отдельные независимые подключения к базе данных), чтобы получить, таким образом, отчеты, которые можно было бы создавать отдельно от приложения (например, если первоначальная постановка задачи не предусматривала каких-то специальных отчетов). Это потребует установки дополнительных компонентов для "привязки" к конкретному источнику данных. Вместе со стандартным пакетом FastReport поставляются, в частности, компоненты для использования FasrtReport с IBX, ADO, BDE и FIBPIus. Автором компонентов FastReport для FIBPIus является Виталий Бармин (barmin@udm.ru).
Итак, если вы хотите использовать и дополнительные возможности FastReport вместе с FIBPIus (этот вопрос будет рассмотрен в разделе "Генератор отчетов FastReport. Создание отчетов в run-time"), то вам необходимо установить соответствующий пакет (FrFib3.dpk, FrFib4.dpk, FrFib5.dpk или FrFib6.dpk, в зависимости от версии Delphi) входящий в поставку FastReport.
Вы также можете всегда найти эти компоненты Виталия Бармина на caйте FIBPlus http://www.fibplus.net/.
Напомним, что сам FastReport вы всегда сможете найти на сайте http://www.fastrepoit.ru
После установки вы увидите в палитре на странице FastReport дополнительный компонент: TfrFIBComponents. Теперь можно перейти к созданию отчета.
Поместим на нашу форму следующие компоненты: frReport: TfrReport; frFIBComponents: TfrFIB Components и frDBDataSetl: TfrDBDataSet (рис. 2.30).
Рис 2.30. Компоненты FastReport
Откроем дизайнер отчетов, дважды нажав на frReport (рис. 2.31).
Рис 2.31. Внешний вид дизайнера отчетов
Как видно из рисунка, оба компонента TpFIBDataSet уже доступны нам в дизайнере. Для начала рассмотрим самый простой вариант отчета, который распечатает нам список категорий товаров в прайс-листе (рис. 2.32).
Рис 2.32. Шаблон отчета о категориях товаров
Для этого мы поместим на страницу четыре полосы (band): Report Title, Page Header, Master Data и Page Footer. Объекты, помещенные на Report Title, будут распечатаны только один раз в самом начале отчета Объекты, размещенные на Page Header, будут выводиться на печать в начале каждой новой страницы. В нашем случае мы просто добавили туда переменную PAGE#, которая будет выводить номер страницы. Master Data нужен нам для вывода данных из компонента CategonesDataSet. Эта полоса (band) будет выведена на печать столько раз, сколько записей в нашем наборе данных. И наконец, Page Footer будет выводиться в конце каждой страницы отчета.
Укажем FastReport, откуда необходимо брать данные для отчета Для этого зададим свойство DataSource у компонента frDBDataSetl (рис. 2 33).
Рис 2.33. Свойства TfrDBDataSet
Теперь необходимо задать источник данных для Master Data Band в самом отчете Нажмите дважды на Master Data в дизайнере отчета и укажите источник данных в появившемся диалоге (рис. 2.34).
Рис 2.34. Источник данных для Master Data
Остается обратить внимание на объект TfrMemoView, в котором и будут выводится названия категорий в отчете (рис 2.35.)
Рис 2.35. Объект шаблона отчета TfrMemoView, необходимый для печати значений поля таблицы
Это выражение вы можете ввести вручную, а можете использовать специальный диалог редактирования объекта и нажать кнопку Insert data field, изображенную на рис 2 36.
На этом этапе фактически отчет готов. Вы можете нажать кнопку Preview и увидеть уже готовый список категорий, который можно распечатать Тем не менее добавим в наше приложение кнопку, которая будет вызывать отчет по названиям категорий товаров
Необходимо написать очень простую обработку нажатия на эту кнопку (предположим, что мы сохранили шаблон для отчета в файле 'price_categories.frf):
procedure TMainForm.PrintBClick(Sender: TObject);
begin
frReport LoadFromFile('price_categories.frf');
frReport PrepareReport;
frReport.ShowPreparedReport,
end;
Рис 2.36. Внешний вид диалога редактирования объекта TfrMemoView
После запуска приложения и нажатия на кнопку Печать мы увидим следующий отчет (рис. 2.37).
Рис 2.37. Вид отчета о категориях товаров в прайс-листе
Работа с BLOB-полями
Достаточно часто желательно хранить в базе данных разнообразные неструктурированные данные: изображения, OLE-объекты, звук и т. д. Специально для этих целей существует специальный тип данных - BLOB Продемонстрируем использование BLOB-полей на примере простого приложения (см. рис. 2.66), использующего следующую таблицу:
CREATE TABLE BIOLIFE (
ID INTEGER NOT NULL,
CATEGORY VARCKAR (15) character set WIN1251 collate
WIN1251,
COMMON_NAME VARCHAR (30) character set WIN1251 collate
WIN1251,
SPECIES_NAME VARCHAR (40) character set WIN1251 collate
WIN1251,
LENGTH_CM_ DOUBLE PRECISION,
LENGTH_IN DOUBLE PRECISION,
NOTES BLOB sub_type 1 segment size 80,
GRAPHIC BLOB sub_type 0 segment size 80);
Для вывода изображений, сохраненных в поле GRAPHIC, мы будем использовать стандартный компонент DBIMagel: TDBImage. Очевидно также, что запросы при работе с BLOB-полями ничем не отличаются от запросов со стандартными типами полей:
SelectSQL:
SELECT * FROM BIOLIFE
UpdateSQL:
UPDATE BIOLIFE Set
ID=?NEW_ID,
CATEGORY=?NEW_CATEGORY,
COMMON_NAME=?NEW_COMMON_NAME,
SPECIES_NAME=?NEW_SPECIES_NAME,
LENGTH__CM_=?NEW_LENGTH_CM_,
LENGTH_IN=?NEW_LENGTH_IN,
NOTES=?NEW_NOTES,
GRAPHIC=?NEW_GRAPHIC
WHERE ID=?OLD_ID
Рис 2.66. Внешний вид формы приложения для работы с BLOB-полями
InsertSQL:
INSERT INTO BIOLIFE(
ID,
CATEGORY,
COMMON_NAME,
SPECIES_NAME,
LENGTH__CM_,
LENGTH_IN,
NOTES,
GRAPHIC
)
VALUES (
?NEW_ID,
?NEW_CATEGORY,
?NEW_COMMON_NAME,
?NEW_SPECIES_NAME,
?NEW_LENGTH_CM_,
?NEW_LENGTH_IN,
?NEW_NOTES ,
?NEW_GRAPHIC
)
DeleteSQL:
DELETE FROM BIOLIFE
WHERE ID=?OLD_ID
RefreshSQL:
SELECT * FROM BIOLIFE
WHERE
ID=?OLD_ID
Единственным отличием от обычных типов данных является то, что для присвоения значения BLOB-параметру необходимо использовать потоки (специализированные потомки стандартного класса TStream). Например, если мы хотим сохранить в нашем поле изображение из внешнего файла, то мы можем написать следующий обработчик нажатия на кнопку:
procedure TMainForm.OpenBClick(Sender: ТОbjесt);
var S. TStream;
FileS: TFileStream;
begin
if not OpenD.Execute then exit;
pFIBDataSetl.Edit;
S : =
pFIBDataSetl.CreateBlobStream(pFIBDataSetl.FieldByName('GRAPHIC') , bmReadWrite);
try
FileS := TFiIeStream.Create(OpenD.FileName, fmOpenRead);
S.CopyFrom(FileS, FileS.Size);
finally
FileS.Free;
S.Free;
pFIBDataSetl.Post;
end;
end;
Обратите внимание на важный момент - перед тем как присваивать значение BLOB-параметру, необходимо перевести pFIBDataSet в состояние редактирования данных. В данном случае это делается безусловным вызовом метода Edit. Вызов метода CreateBlobStream создает экземпляр специального внутреннего класса TFIBDSBlobStream. Скорее всего, вам не придется использовать этот класс напрямую. В нашем примере он нужен только для обмена данными между BLOB-параметром и потоком, который читает данные из файла с изображением. Параметр bmReadWrite означает, что мы собираемся изменять содержимое параметра. Поток S напрямую связан с BLOB-параметром, поэтому, копируя данные из файла (FileS) в поток S, мы фактически присваиваем значение параметру. Остается только сохранить изменения вызовом метода Post Аналогичным образом мы можем сохранить значение BLOB-поля в некоторый внешний файл:
procedure TMainForm.SaveBClick(Sender: TObject);
var S: TStream;
FileS: TFiIeStream;
begin
if not SaveD.Execute then exit;
if not pFIBDatasetl.FieldByName('GRAPHIC').IsNull then begin
S : =
pFIBDatasetl.CreaceBlobStream(pFIBDatasetl.FieldByName('GRAPHIC '), bmRead);
try
if FileExists(SaveD.FileName) then
FileS := TFileStream.Create(SaveD.FileName, fmOpenWrite)
else
FileS := TFileStream.Create(SaveD.FileName, fmCreate);
FileS.CopyFrom(S, S.Size);
finally S.Free;
FileS.Free;
end;
end;
end;
Обратите внимание, что в этой процедуре мы используем параметр bmRead при создании потока S. Очевидно, что для сохранения содержимого BLOB-поля в файл нам не нужно изменять само поле, поэтому мы создаем поток только для чтения. Еще более простым способом мы можем очистить содержимое BLOB-поля:
procedure TMainForm.ButtonlClick(Sender: TObject);
begin
pFIBDataSetl .Edit;
pFIBDataSetl.FieldByName('GRAPHIC').Clear;
pFIBDataSetl.Post;
end;
В этом случае даже не требуется создавать какие-либо потоки. Иногда также нужно знать, является ли BLOB-поле пустым или нет. При использовании визуальных компонентов типа TDBImage мы не можем быть в этом уверены. Согласитесь, что никто не мешает нам "нарисовать" пустую картинку и сохранить ее в BLOB-поле В этом случае мы не сможем отличить "на глаз": есть ли какое-то изображение в BLOB-поле или нет. Однако мы можем написать обработчик события OnDataChange компонента DataSourcel: TDataSource:
procedure TMainForm.DataSourcelDataChange(Sender: TObject;
Field: TField) ;
begin
CheckBoxl.Checked :=
pFIBDataSetl.FieldByName('GRAPHIC').IsNull;
end;
Это событие вызывается, в частности, при навигации по DBGridl; таким образом, мы всегда можем узнать, является ли текущее поле пустым или нет.
Если вы используете TpFIBQuery для работы с BLOB-полями, то общий принцип остается тем же - необходимо использовать потоки, однако, в отличие от TpFIBDataSet, вам не потребуется создавать какие-то специальные потоки. Например, мы можем написать следующую процедуру, которая сохранит в файлы все изображения из нашей таблицы:
pFIBQuery.SQL: SELECT * FROM BIOLIFE
procedure TMainForm.Button2Click(Sender: TObject);
var SaveFile: TFileStream;
Index: Integer;
begin
with pFIBQueryl do begin ExecQuery;
Index := 1;
while not Eof do begin
SaveFile := TFileStream.Create(IntToStr(Index) + '.bmp',
fmCreate);
FN('GRAPHIC').SaveToStream(SaveFile);
Next;
inc(Index);
SaveFile.Free;
end;
Close;
end;
end;
Метод FN является аналогом FieldByName.
Смысл кода, приведенного выше, совершенно очевиден: мы получаем все записи из таблицы BIOLIFE, в цикле получаем от сервера очередную запись из запроса, создаем файл при помощи потока SaveFile, сохраняем в него значение поля GRAPHIC и запрашиваем следующую запись при помощи метода Next. Аналогичным образом мы могли бы присваивать значение BLOB-параметру: pFIBQuery.SQL: INSERT INTO BIOLIFE (GRAPHIC) VALUES (7GRAPHIC)
procedure TMainForm.Button2Click(Sender: TObject);
var SaveFile: TFileStream;
Index: Integer;
begin
with pFIBQueryl do begin Prepare;
for Index := 1 to 3 do begin
SaveFile := TFileStream.Create(IntToStr(Index) + '.bmp', fmOpenRead);
Params[0].LoadFromStream(SaveFile);
SaveFile.Free;
ExecQuery;
end;
Transaction.Commit;
end;
end;
Данный пример вставляет три новые записи в таблицу BIOLIFE и сохраняет в них изображения из некоторых файлов "l.bmp", "2.bmp" и "3.bmp".
Поскольку в данном примере для сохранения изменений использовался метод Commit, то необходимо перезапустить приложение, чтобы увидеть вставленные записи в DBGridl.
Разделенные транзакции: уникальная возможность избежать Deadlock. Режим AutoCommit
CategoriesDataSet позволяет автоматически подтверждать сделанные изменения, если задать свойство AutoCommit в True. Теперь после вызова метода Post компонент CategoriesDataSet будет автоматически вызывать CategonesTransaction CommitRetainmg, сохраняя сделанные пользователем изменения и не закрывая при этом сам запрос. Такой подход уже снижает вероятность Deadlock, который возможен при наличии длинных незакрытых транзакций, в контекст которых производились изменения данных.
Тем не менее, FIBPlus предлагает другую возможность, которая сводит вероятность возникновения Deadlock практически к нулю. TpFIBDataSet может работать одновременно в контексте двух транзакций. Одна длинная транзакция, в контексте которой данные только читаются, и другая короткая транзакция, в контексте которой выполняются все модифицирующие запросы.
Переименуем CategoriesTransaction в CategoriesReadTransaction и добавим еще один компонент CategoriesWriteTransaction. После этого зададим свойство UpdateTransaction у CategoriesDataSet в CategoriesWriteTransaction. Таким образом, теперь CategoriesDataSet подключен сразу к двум компонентам TpFTBTransaction (рис. 2.26).
Рис 2.26. Разделение читающей и пишущей транзакций
После вызова метода Post компонент CategoriesDataSet будет вызывать метод Commit у компонента CategoriesWriteTransaction. Однако, учитывая, что данные читаются в контексте совсем другой транзакции (CategoriesReadTransaction), это не вызовет закрытия всего CategoriesDataSet. To есть, используя FIBPlus, мы имеем настоящий режим AutoCommit, который уменьшает вероятность Deadlock и не мешает "видеть" нам актуальные значения всех записей. При использовании BDE в режиме AutoCommit вы не могли бы узнать реальные значения записей, пока не переоткроете запрос.
Кроме того, как уже упоминалось, для InterBase до версии 6.5 слишком частый вызов CommitRetaining мог привести к значительному "захвату" ресурсов сервером. При использовании механизма разделенных транзакций вы можете использовать режим AutoCommit без потерь производительности сервера для любых версий InterBase.
Разработка приложений баз данных InterBase на Borland Delphi/C++ Builder/Kylix
Что такое InterBase Express?
Общее описание основных компонентов, включенных в состав IBX
Компоненты-оболочки для Services API
Использование основных компонентов InterBase eXpress (IBX)
Иерархия компонентов в IBX
Особенности TIBTable, TIBQuery и TIBStoredProc
TIBTable
TIBQuery
TIBStoredProc
Подключение к базе данных
Управление транзакциями
Выполнение запросов при помощи TIBDataSet
Редактируемые запросы
Редактирование данных при помощи визуальных компонентов
Программное редактирование данных
И снова про транзакции
Использование генераторов для автоинкрементных полей
Механизм master-detail
Заключение
Что такое FIBPlus?
Общее описание компонент, включенных в состав FIBPlus
Использование основных компонентов FIBPlus
Подключение к базе данных, выполнение простых запросов
Управление транзакциями
Использование стандартных визуальных db-компонентов совместное FIBPlus
Как сделать запрос редактируемым? Автоматическая генерация модифицирующих запросов в design-time и run-time
Правильный способ использования auto-increment полей в FIBPlus
Разделенные транзакции: уникальная возможность избежать Deadlock. Режим AutoCommit
Механизм master-detail. Специальные опции TpFIBDatabase и TpFIBDataSet
Специальные опции в компонентах FIBPlus
Опции и настройки TpFIBDatabase
Опции и настройки TpFIBDataSet
Использование FIBPlus совместно с генератором отчетов FastReport
Простой отчет
Отчеты вида master-detail
Создание отчетов в run-time
Использование специальных инструментов в design-time: FIBPlus
Tools
Установка FIBPlus Tools
Preferences
SQL Navigator
Специальные возможности FIBPlus
Обработка потери подключения к базе данных
Эмуляция Boolean-полей
Поддержка array-полей. Пример использования TpFIBUpdateObject и TDataSetContainer
Работа с BLOB-полями
Локальная сортировка и локальная фильтрация
Локальная сортировка
Локальная фильтрация
Обработка событий InterBase при помощи FIBPlus
"Низкоуровневая" работа с внутренним буфером TpFIBDataSet
Редактирование данных при помощи визуальных компонентов
Если вы уже запустили пример, представленный выше, и попробовали исправить хотя бы одну запись в таблице, то наверняка получили сообщение, что сделать это невозможно. Причины этого сообщения очевидны, поскольку компонент IBDataSetl имеет только свойство SelectSQL. Это свойство содержит запрос на выборку записей, его выполнение позволяет получить список тех записей из таблицы EMPLOYEE с сервера, которые удовлетворяют условию в WHERE.
А для того чтобы, к примеру, исправить какую-либо запись, необходимо выполнить команду UPDATE. В общем случае выполнение этой команды может вообще не зависеть от нашего запроса в SelectSQL.
Но поскольку TIBDataSet был спроектирован в первую очередь для того, чтобы использоваться совместно со стандартными визуальными компонентами, то он предоставляет нам средства для автоматического выполнения тех модифицирующих запросов, которые необходимы для изменения данных, полученных при помощи SelectSQL. Чтобы окончательно не запутаться, давайте подробнее рассмотрим этот вопрос.
Итак, мы открыли запрос в SelectSQL. Как видно из рисунка, первая полученная запись содержит имя сотрудника Robert. Предположим, мы хотим исправить это имя на John.
В момент изменения произойдет следующее: в локальном буфере IBDataSetl у текущей записи значение поля FIRST_NAME будет изменено с Robert на John. В базе данных данное изменение пока никак не отражается. Чтобы произвести фактическое изменение данных на сервере, необходимо выполнить соответствующий запрос с UPDATE. Этот запрос необходимо заранее указать у компонента IBDataSetl в свойстве ModifySQL:
UPDATE EMPLOYEE
SET
EMP_NO = :EMP_NO,
FIRST_NAME = :FIRST_NAME,
LAST_NAME = :LAST_NAME,
PHONE_EXT = :PHONE_EXT,
HIRE_DATE = :HIRE_DATE,
DEPT__NO = :DEPT_NO,
JOB_CODE = :JOB_CODE,
JOB_GRADE = :JOB_GRADE,
JOB_COUNTRY = :JOB_COUNTRY,
SALARY = :SALARY WHERE
EMP_NO = :OLD_EMP_NO
Как видно из примера, вместо реальных значений в этом запросе указаны параметры, названия которых совпадают с названием реальных полей. Таким образом, когда пользователь изменит значения полей конкретной записи, ю jtBDataSetl сам задаст значения всех параметров, взяв их из соответствующих |полей. В частности, значение параметра :FIRST_NAME будет равно John. Запрос шз ModifySQL выполнится, и только после этого изменения, сделанные пользователем, окажутся в базе данных.
Аналогичная последовательность действий связана с запросами в свойствах HnsertSQL и DeleteSQL - они выполняются при вставке новой записи и удалении записи пользователем.
Обратите внимание на префикс OLD_ в названии параметра :OLD_EMP_NO. Данный префикс означает, что IBDataSet должен подставить в параметр значение поля до изменения пользователем.
Итак, если мы сформируем все модифицирующие запросы, то наш IBDataSet позволит пользователям редактировать данные, т. е. мы фактически получим запрос, который разработчики на Delphi/C-H-Buildei обычно называют "живым"(live query).
Существует еще одна важная особенность при создании "живых" запросов После выполнения любого модифицирующего действия IBDataSet 1 выполнит запрос, указанный в свойстве RefreshSQL. Этот запрос должен возвращать только одну запись - текущую и нужен для обновления значений полей текущей записи после сделанных исправлений.
SELECT
EMP_NO,
FIRST_NAME,
LAST_NAME,
PHONE_EXT,
HIRE_DATE,
DEPTMTO,
JOB_CODE,
JOB_GRADE,
JOB_COUNTRY,
SALARY,
FULL_NAME
FROM EMPLOYEE
WHERE
EMP_NO = :EMP_NO
Смысл данного запроса становится очевидным, если допустить существование в базе данных триггеров для таблицы EMPLOYEE, которые модифицируют значения полей. Поскольку изменения происходят в самой базе данных сразу после вставки или после изменения записей, то без повторного перечитывания записи (т. е. без Select только что вставленной или измененной записи), мы не узнаем о тех изменениях, которые были сделаны в триггерах. Можно, конечно, вообще переоткрыть весь запрос, заданный в SelectSQL.
Именно такой механизм и реализуется в BDE, когда мы вынуждены целиком переоткрывать все запросы. В IBX без этого легко можно обойтись, используя RefieshSQL, значительно сэкономив при этом сетевой трафик и снизив нагрузку на сервер, поскольку получение всего лишь одной измененной записи гораздо более эффективно, чем переоткрытие запроса целиком.
IBX предоставляет нам возможность быстро сгенерировать необходимые модифицирующие запросы при помощи редактора IBDataSet (рис 2.9.)
Выбрав из списка Table Name нашу таблицу и нажав кнопку Get Table Fields мы сформируем списки Key Fields и Update Fields. В списке Key Fields нужно выделить те поля, которые будут формировать условие WHERE в наших запросах. Очевидно, что это должны быть поля, которые определяют первичный ключ у таблицы. Если такой ключ существует для выбранной таблицы, то вы можете просто нажать на кнопку Select Primary Keys, чтобы автоматически выделить нужные поля.
Рис 2.9. Генератор модифицирующих запросов
В списке Update Fields необходимо выделить те поля, которые потом пользователь сможет редактировать. На рисунке видно, что поле FULL_NAME не включено в список, поскольку это CALCULATED-поле и его значение нельзя менять
К сожалению, надо самому точно знать, какие поля необходимо исключать из модифицирующих запросов поскольку компоненты не дадут ни одной подсказки. Даже при подготовке данного раздела пришлось потратив впустую некоторое время, чтобы понять, почему IBDataSetl никак не "хотел" становиться модифицируемым. Только выяснив, что поле FULL_NAME является вычислимым, стало понятно, почему возникает ошибка IBDataSetl пытался выполнить команду Prepare для каждого из запросов и сервер каждый раз сообщал, что не может изменить read-only-поле! Хочется отметить, что этой проблемы нет в генераторе запросов, реализованном в FIBPlus.
Остается нажать кнопку Generate SQL, чтобы получить все запросы flnsertSQL, ModifySQL, DeleteSQL и RefreshSQL.
Создание отчетов в run-time
Одной из самых замечательных особенностей FastReport является возможность создавать отчеты прямо в run-time, т. е. во время работы приложения. Это позволяет добавлять в ваше приложение отчеты, которые не были предусмотрены заранее, и использовать в этих отчетах как существующие запросы, так и совершенно новые. Более того, фактически вы можете создавать в таких отчетах даже самостоятельные подключения к базам данных не меняя код вашей программы!
Все это возможно благодаря архитектуре FastReport и компонентам, написанным Виталием Барминым, о которых мы уже упоминали выше.
Для этого добавим в наше приложение компоненты TfrDesigner, TfrDialogControls (как видно из названия, этот компонент предназначен для построения и использования самостоятельных диалоговых окон в составе отчета), а также кнопку для вызова диалога редактирования шаблона отчета (рис. 2.41).
Обработчик для этой кнопки будет исключительно простым:
procedure TMainForm.DesignPClick(Sender: TObject);
begin
frReport.DesignReport;
end;
Теперь при запуске приложения мы можем нажать на кнопку "Дизайн отчетов" и создать отчет прямо в run-time, сохранить его в отдельном файле и потом использовать в приложении. Все эти шаги, в сущности, являются тем же самым, что мы уже делали в предыдущих разделах. Теперь же мы хотим сосредоточиться на дополнительных возможностях FastReport, а именно на создании независимых отчетов.
Рис 2.41. Компоненты для встраивания дизайнера отчетов в программу
Если вы обратите внимание, то шаблон для отчета по умолчанию имеет одну страницу, на которой мы и располагаем полосы для печати. Добавим к отчету специальную страницу - диалоговую, на которой расположим компоненты доступа к данным (рис. 2.42).
Рис 2.42. Добавление диалоговой страницы к шаблону отчета
После добавления диалога и перехода на страницу 2 нашего шаблона на панели инструментов с объектами, доступными для отчета, вы увидите ряд визуальных компонентов, которые можно располагать на диалоге (рис. 2.43).
Рис 2.43. Компоненты для доступа к базе данных из шаблона отчета
Положим на диалог компонент Query: TfrFIBQuery, укажем ему существующее подключение к базе данных в свойстве Database и напишем следующий запрос в свойстве SQL:
SELECT "Categories"."Name", "Categories"."GoodsCount"
FROM "Categories"
WHERE "Categories"."GoodsCount" > 0
Очевидно, что мы хотим вывести на печать только те категории товаров, количество наименований по которым больше нуля. Остается только создать сам шаблон печати, привязав соответствующие полосы (bands) к Query как к источнику данных (рис. 2.44).
Рис 2.44. Шаблон встроенного отчета
Укажем источник данных для Master Data (рис. 2.45).
Рис 2.45. Подключение полосы (band) к встроенному в шаблон запросу
И сохраним наш новый отчет, например, под именем "pricel.frf". Теперь можно несколько изменить реакцию нашего приложения на нажатие кнопки печати. Положим на форму компонент OpenDialog: TopenDialog - и напишем следующий обработчик нажатия на кнопку "Печать":
procedure TMainForm.PrintBClick(Sender: TObject);
begin
if not OpenDialog.Execute then exit;
GoodsDataSet.DetailConditions :=
GoodsDataSet.DetailConditions [dcWaitEndMasterScroll];
frReport.LoadFromFile(OpenDialog.FileName);
frReport.PrepareReport;
frReport.ShowPreparedReport;
GoodsDataSet.DetailConditions :=
GoodsDataSet.DetailConditions + [dcWaitEndMasterScroll] ;
end;
Таким образом, когда пользователь нажмет на кнопку "Печать", он сможет выбрать любой шаблон отчета и вывести его на печать. Учитывая, что при помощи дизайнера отчетов тот же самый пользователь (или вы, как разработчик) может подготовить неограниченное количество самых разных отчетов без необходимости изменения основного кода приложения, становится очевидным преимущество использования FIBPlus совместно с FastReport. Конечно, возможность создавать отчеты в run-time доступна в FastReport и для других пакетов работы с данными, в частности с IBX, однако FIBPlus делает эту возможность значительно более гибкой за счет использования макросов. Более подробно механизм макросов мы рассмотрим чуть позже, а сейчас лишь продемонстрируем, как, используя макросы, мы можем создавать более функциональные диалоговые отчеты.
Скопируем "pricel.frf" в "price2.frf", откроем "price2.frf" для редактирования в дизайнере отчетов и перейдем на диалоговую страницу. Там мы поместим дополнительные компоненты: ComboBoxl, Editl, Labell и Buttonl (рис. 2.46).
Рис 2.46. Внешний вид диалога, встроенного в шаблон отчета
Изменим запрос в Query.SQL:
SELECT "Categories"."Name", "Categories"."GoodsCount"
FROM "Categories"
WHERE "Categories"."GoodsCount" @COND
COND в данном случае является макросом FIBPlus, и вместо него мы можем поставить любой текст. Удобство же заключается прежде всего в том, что макросы в FIBPlus рассматриваются как полноценные параметры, а значит, FastReport тоже будет считать, что в данном случае имеет дело с параметром. В данном примере мы можем позволить пользователю самому указать условия для выборки категорий прайс-листа. Заполним ComboBoxl.Items символами сравнения:
>
<
>=
< =
<>
=
Теперь нам достаточно только указать FastReport, какое значение необходимо "подставить" вместо нашего макроса-параметра. Для этого надо изменить свойство Params у компонента Query (рис. 2.47).
Рис 2.47. Выражение для получения значение макроса COND
Параметр у нас один: COND. Его значение мы должны сформировать из двух частей: знака сравнения и значения, с которым будет сравниваться поле "GoodsCount". Что и было сделано, как видно из рисунка выше. Теперь при запуске отчета мы увидим диалог, в котором необходимо указать условие для выборки (рис. 2.48).
Рис 2.48. Полученный диалог во время получения отчета
А на рис. 2.49 изображен получившийся отчет о категориях товаров, в которых более семи наименований товаров.
Теперь мы можем определить реакцию на щелчок по любой категории товаров в подобном отчете таким образом, чтобы по нему выводился полный отчет о товарах из этой категории. Для этого у всех объектов FastReport есть свойство Tag: String. В окне preview пользователь может нажать на объект и при этом выполнится какое-либо действие (например, построится другой отчет). Цель свойства - облегчить распознавание нажатого объекта. Например, объект может содержать текст "12.25р", по которому идентификация невозможна. Но в свойство Tag можно поместить более развернутую информацию, например значение ключа таблицы, из которой был получен текст "12.25р", номер строки или колонки в отчете и пр. При этом необходимо использовать событие TfrReport.OnObjectClick.
Рис 2.49. Внешний вид получившегося динамического отчета
Логично использовать для вывода детализованного отчета тот же самый объект frReport, который уже лежит у нас на диалоговой форме приложения. Однако саму форму этого отчета надо будет разработать отдельно и сохранить на диске. Форма отчета будет выглядеть так же, как и в нашем отчете master-detail (рис. 2.50).
Кроме того, нам будет необходимо наложить фильтр на категории товаров:
SELECT "Categories"."Name", "Categories"."GoodsCount"
FROM "Categories"
WHERE "Categories"." Name " @NAME
Теперь укажем FastReport, какое значение следует подставить вместо макроса "@NAME" в компоненте Query. Здесь нам придется немного "схитрить" и присвоить этому макросу значение переменной FastReport. Назовем эту переменную Va .
К самой переменной мы присвоим значение в коде программы.
Сохраним эту форму отчета из дизайнера на диске в текущем каталоге под именем "detailed.frf".
Рис 2.50. Шаблон дополнительного отчета
Определим в коде программы для TfrReport событие OnObjectClick следующим образом:
procedure Tforml.frReportObjectClick(View: TfrView);
var str: string;
begin
str .= View.Memo.Text;
frReport.LoadFromFile('detailed.frf')
frReportl.Dictionary.Variables['Varl'] := str;
if frReport.PrepareReport then begin
frReport.OnObjectClick := nil; { чтобы при щелчке на детализованном отчете не показывался детализованный отчет }
frReport.ShowPreparedReport;
frReport.OnObjectClick := frReportObjectClick; { возвращаем событие для вывода детализованного отчета }
frReport.ShowReport;
end;
end;
Наиболее полную документацию, описание всех возможностей, а также последние версии FastReport можно найти на официальном Web-сайте http://www.fastreport.ru.
SQL Navigator
Это наиболее интересная часть FIBPlus Tools, не имеющая аналогов в других продуктах. Фактически это инструмент централизованной обработки SQL в рамках целого приложения (рис. 2.54):
Рис 2.54. Внешний вид SQL Navigator
SQLNavigator позволяет разработчику сосредоточиться на написании и анализе SQL-кода в приложении. Нажмите кнопку Scan all forms of active project. SQLNavigator переберет все формы приложения и выделит из них те, которые содержат компоненты FIBPlus для работы с SQL: TpFIBDataSet, TpFIBQuery, TpFIBUpdateObject и TpFffiStoredProc. Нажмите в списке на любую из обнаруженных форм. Список справа будет заполнен компонентами, обнаруженными на этой форме. Нажатие на любой из компонентов позволит нам посмотреть соответствующие свойства, в которых содержится SQL-код. Для компонентов класса TpFIBDataSet будут выведены свойства: SelectSQL, InsertSQL, UpdateSQL, DeleteSQL и RefreshSQL Для компонентов TpFIBQuery, TpFIBUpdateObject и TpFIBStoiedPioc будет выведено значение свойства SQL
Вы можете изменить любое свойство напрямую из SQLNavigator, и новое значение будет сохранено SQLNavigator позволяет делать операции с группами компонентов Для этого достаточно пометить соответствующие компоненты или даже формы (рис. 2.55).
Рис 2.55. Выделение группы компонентов при помощи SQL Navigator
Теперь мы можем сохранить значения выделенных свойств во внешнем файле при помощи кнопки Save selected SQLs или проверить их корректность прямо в SQLNavigator при помощи кнопки Check selected SQLs Записанный файл с выделенными запросами можно использовать для дальнейшего анализа при помощи специализированных инструментов
Вы можете использовать SQLNavigator для поиска текста в SQL в рамках всего проекта Например, на рис. 2 56 вы можете видеть все свойства в проекте, которые содержат строку "ID"
При помощи двойного нажатия на каждом найденном элементе SQLNavigator выберет компонент и свойство, чтобы разработчик мог редактировать SQL.
Таким образом, SQLNavigator представляется очень эффективным инструментом для работы с SQL-кодом в клиентской части приложения базы данных, пожалуй, единственным в своем роде
Рис 2.56. Результат поиска текста в запросах FIBPIus
TIBQuery
Аналогично ТГВТаЫе-компонент TIBQuery скрывает запросы для получения и редактирования данных. Вместо скрытого в этом компоненте свойства SelectSQL разработчику предлагается использовать свойство SQL. На самом деле после присвоения свойства SQL компонент присваивает его значение свойству SelectSQL.
Но самое примечательное с точки зрения проектирования классов начинается тогда, когда мы хотим сделать наш запрос редактируемым (live-query).
Поскольку свойства DeleteSQL, InsertSQL и ModifySQL спрятаны, то TIBQuery сам по себе не может предоставить разработчику редактируемые запросы.
Однако, как уже было сказано, TIBQuery был сделан как аналог TQuery и для полной аналогии в ГВХ введен компонент TIBUpdateSQL. Он содержит собственные свойства DeleteSQL, InsertSQL и ModifySQL и может подключаться к TIBQuery. После чего TIBQuery начинает использовать свойства компонента TIBUpdateSQL для редактирования собственных данных! Получается, что готовую функциональность TIBCustomDataSet, уже заложенную в него с самого на- чача, приходится дублировать в отдельном компоненте.
Отметим, тем не менее, что в данной связке имеется несомненный смысл, если речь идет о миграции готовых BDE-приложений на IBX. В общем-то, вероятно, только ради этого данные классы и были введены
Мы можем принять это как выгоду с точки зрения замены старых BDE-компонентов на нечто похожее из IBX, однако, если вы пишете новое приложение, которое с самого начала базируется на IBХ, мы бы рекомендовали вам использовать TDBDataSet как вместо ТIBTable, так и вместо TffiQuery.
Некоторые разработчики используют TIBQuery для выполнения только модифицирующих запросов, т. е. тех, которые не возвращают результата. Например, это может быть запрос с предложением INSERT или DELETE.
Для выполнения запросов, не возвращающих результирующий набор данных. в TIBQuery предусмотрен метод ExecSQL. Но фактически, как видно из исходных текстов компонента, вызов данного метода не отличается от вызова метода Open, который унаследован от TIBCustomDataSet.
Поэтому для выполнения запросов, которые не возвращают результатов (в том смысле, что не возвращают набор результирующих строк), не имеет смысла использовать компоненты, предназначенные для взаимодействия с визуальными db-aware- компонентами. Вместо этого лучше использовать компонент TIBSQL, который не буферизует получаемые данные и предназначен именно для простого и быстрого выполнения SQL-запросов, в частности не возвращающих набор строк.
TIBStoredProc
Данный компонент предназначен для выполнения исполняемых (executed) хранимых процедур. Он также является потомком TffiCustomDataSet и полностью совместим с визуальными компонентами.
Являясь прямым наследником TffiCustomDataSet, компонент TffiStoredProc прячет все основные свойства предка и добавляет такое свойство, как ProcedureName.
Следует понимать, что в данном случае слово "прячет" относится больше к идеологии проектирования классов, нежели к технической стороне дела. Очевидно, что спрятать свойства предка в Object Pascal нельзя. TIBCustomDataSet уже имеет все необходимые свойства, которые уже готовы для публикации, их просто не вынесли в секцию published. И хотя мы согласимся, что в данном случае нельзя однозначно сказав, насколько правильным является данное проектирование классов, однако считать его красивым довольно трудно.
В результате указания названия процедуры (например, procl) компонент сформирует SQL-запрос следующего вида:
EXECUTE PROCEDURE Proс1
В целом возможно, что проще вызвать хранимую процедуру с помощью соответствующего SQL-запроса, используя TIBDataSet, если мы хотим показать результат в db-aware-компонентах, или TIBSQL, если мы хотим вызывать хранимую процедуру вида executable (т. е. не возвращающую набор данных).
Единственным преимуществом использования TIBStoredProc по сравнению с TIBDataSet является тот факт, что TIBStoredProc самостоятельно формирует список параметров процедуры по ее имени, обращаясь к системным таблицам.
TIBTable
Компонент ТШТаЫе прячет все указанные выше свойства, а вместо этого пользователю предоставляется свойство TableName. Пользователь указывает имя таблицы в свойстве TableName, а компонент автоматически формирует набор "спрятанных" запросов.
Например, для таблицы с именем Tablel запрос в SelectSQL будет иметь вид:
SELECT * FROM Tablel
Легко представить, что в нашей таблице несколько миллионов записей и этот запрос попытается получить их их в полном объеме на клиента. Например, при вызове Locate, который так любят пользователи BDE, если запись, соответствующая условиям поиска, не найдена в загруженном наборе записей, то TIBTable будет запрашивать оставшиеся записи, пока не найдется подходящая запись или пока не закончатся записи в таблице.
Очевидно, что это вызовет колоссальную нагрузку на SQL-сервер и клиента, особенно в многопользовательской среде. Ни один специалист не рекомендует использование компонента TIBTable в реальных программных проектах, предназначенных для управления серьезными базами данных в многопользовательской среде.
Управление транзакциями
Необходимо помнить, что любое действие с базой данных происходит в рамках той или иной транзакции. Работа с InterBase основана на явном управлении транзакциями, а поскольку библиотека IBX - это обертка вокруг соответствующих функций InterBase API, то использование этих компонентов также предполагает, что программист явным образом будет управлять транзакциями из своего приложения. Для контроля транзакций в IBX существует специальный компонент TIBTransaction (рис. 2.4):
Рис 2.4. Свойства TIBTransaction
Как видно из рисунка, компонент не слишком перегружен свойствами. Фактически основным является свойство Params, в котором можно указать уровень Изоляции транзакции. Для этого необходимо знать соответствующие системные •константы из InterBase API. Однако для большинства ситуаций вам вполне хватит использования одного из четырех заранее заданных уровней изоляции. Для того чтобы выбрать один из них, можно вызвать редактор компонента (рис. 2.5).
Рис. 2.5. Вызов редактора TIBTransaction
В появившемся диалоге вы сможете указать нужный уровень изоляции, а заодно и увидеть сразу, какими константами он задается (рис. 2.6.).
Рис 2.6. Редактор TIBTransaction
Для большинства случаев рекомендуется использовать режим Read Committed, который позволит запросам в одной транзакции "видеть" изменения, сделанные и подтвержденные в контексте других транзакций.
TIBTransaction ссылается на компонент базы данных при помощи свойства DetaultDatabase. Если также указать свойство DefaultTransaction у TIBDatabase, то в дальнейшем любые компоненты (TIBDataSet, TffiSQL и т. д.), которые ссылаются на TIBDatabase, будут автоматически "подхватывать" и указанную транзакцию.
Теперь рассмотрим свойства AllowAutoStart и AutoStopAction. Как вам уже известно, любой запрос к базе данных должен выполняться в контексте транзакции. То есть, прежде чем выполнить даже простейший запрос вида SELECT * FROM TABLE 1, необходимо предварительно запустить транзакцию при помощи вызова IBTransaction.StartTransaction.
Такой "ручной" вызов не всегда удобен. Более того, каждый раз совершенно определенно известно: если мы хотим выполнить запрос, то мы должны запустить транзакцию. Чтобы избежать лишнего кода, связанного с запуском транзакций, можно установить значение свойства AllowAutoStart равным True. В этом случае если мы попробуем, например, открыть TIBDataSet, то он сам автоматически запустит соответствующую транзакцию.
Аналогичный смысл имеет свойство AutoStop Action. Когда мы закрываем все запросы, выполнявшиеся в контексте автоматически запущенной транзакции, то TIBTransaction выполняет действие, указанное в AutoStopAction. Например, автоматически подтверждает всю транзакцию при помощи метода Commit, если свойство AutoStopAction равно saCommit. Таким образом, разработчику предоставляется возможность указать, как компоненты должны автоматически взаимодействовать друг с другом!
Фактически любые действия с данными должны происходить в контексте той или иной транзакции. Управление транзакциями в FIBPlus осуществляется при помощи компонентов класса TpFIBTransacdon. Все транзакции в FIBPlus являются "явными" (explicit) и запускаются при помощи метода StartTransaction. Тем не менее, чтобы вы могли избежать лишнего кодирования, TpFIBDataSet и TpFIBQuery самостоятельно запускают транзакции, если установлен ключ poStartTrasaction в свойстве Options. Завершать транзакцию в любом случае необходимо явным образом при помощи вызова соответствующих методов: Commit, Rollback, CommitRetaining и RollbackRetaining
Метод CommilRetammg появится в InteiBase только начиная с версии 5.1, а метод RollbaekRetammg - только в версии 6.0.
Планируя внутреннюю организацию транзакций в приложении, необходимо помнить про уровень изоляции транзакций Можно указывать уровень изоляции транзакции явным образом при помощи соответствующих констант InterBase в свойстве TRPaiams или используя заранее заданные уровни изоляции при помощи свойства TPBMode. По умолчанию любой компонент TpTransaction, помещенный на форму, имеет уровень изоляции "Read Committed".
FIBPlus также позволяет создавать и запоминать в системном реестре пользовательские уровни изоляции (свойство UserKmdTransaction) Необходимо вызвать редактор компонента, нажав на нем правой кнопкой мыши, и выбрать пункт "Edit transaction params" (рис. 2.16).
Рис 2.16. Редактор компанента TpFIBTransaction
После нажатия на кнопку New Kind нужно указать название для набора констант и перечислить необходимые константы в поле Settings. Теперь нужно сохранить константы нажатием кнопки Save kind Описания всех констант вы можете узнать в документации к InterBase В дальнейшем, вы можете использовать собственные созданные наборы констант, выбирая названия из списка в свойстве UserKmdTiansaction
Закрытие транзакции также имеет ряд особенностей, которые необходимо иметь в виду разработчикам Если вы закрываете транзакцию вызовом методов Commit или Rollback, то все активные запросы, которые работают в контексте этой транзакции, будут также закрыты. Такое поведение непривычно для разработчиков, ранее использовавших в своих приложениях BDE, где подтверждение транзакции оставляло курсоры открытыми. Нужно подчеркнуть, что механизм, реализованный в BDE, является лишь эмуляцией. То есть фактически завершение транзакции просто вызывало невидимое автоматическое "переоткрытие" всех активных запросов. Кроме того, важно иметь в виду, что все запросы при использовании BDE работают в контексте одной и той же транзакции, в отличие от FDBPlus, где каждый запрос может работать в рамках своей отдельно взятой транзакции.
Тем не менее если вы не хотите, чтобы подтверждение транзакции вызывало закрытие всех активных TpFIBDataSet, то вы можете использовать метод CommitRetaining. Этот метод подтверждает транзакцию и автоматически запускает новую с теми же самыми параметрами, не закрывая при этом пользовательских курсоров (запросов, выбирающих данные)
Данный метод содержал ошибку реализации, поэтому не рекомендуется слишком часто вызывать CommitRetaining для версий Intel Base меньше чем 6.5.
То же самое касается и метода RollbackRetaining, который отменяет изменения, сделанные в контексте транзакции и запускает новую.
Данный метод появился в InteiBase версии 6.0.
Установка FIBPIus Tools
FIBPIus Tools - это эксперты для Delphi и C++ Builder, поставляющиеся в готовом, скомпилированном виде, поэтому для их установки в среде необходимо установить соответствующий пакет.
На момент создания книги опубликованы FIBPIus Tools для Borland Delphi 3-7 и Borland C++ Builder 5-6. Если вы используете другие версии продуктов Borland, мы рекомендуем вам проверить более новые версии FIBPIus Tools на сайте http://www.tlbplus.net/.
Рассмотрим установку в среде Delphi (рис. 2.51). Необходимо выбрать пункт основного меню Components -> Install Packages.
Рис 2.51. Установка FIBPIusTools в среду Delphi
Нажмите на кнопку Add и найдите соответствующий вашей версии Delphi пакет (табл. 2.1).
Табл 2.1. FIBPlusTools: Поддерживаемые версии Delphi/C++ Builder
|
Версия Delphi/C++ Builder |
Название пакета FIBPIus Tools | ||
|
Delphi 3 |
PFIBPIusTools3.dpl | ||
|
Delphi 4 |
pFIBPIusTools4.bpl | ||
|
Delphi 5 |
pFIBPIusToolsS.bpl | ||
|
Delphi 6 |
PFIBPIusTools6.bpl | ||
|
Delphi 7 |
PFIBPIusTools7.bpl | ||
|
C++ Builder 5 |
PFIBPIusTools_CB5.bpl | ||
|
C++ Builder 6 |
pFIBPIusTools_CB6.bpl |
После установки вы обнаружите пункт FIBPIus в основном меню Delphi (рис. 2.52).
Рис 2.52. Меню FIBPIus Tools
Последний пункт в меню FIBPIus фактически ничего не делает, но показывает номер установленной версии.
Выполнение запросов при помощи TIBDataSet
В данной главе сознательно не рассматривается работа с TIBTable или TIBQuery, так как авторы книги не считают их использование целесообразным. Если вы все же желаете использовать эти компоненты (например, для облегчения миграции приложения с BDE), то для из>че- ния их функций можно обратиться к документации по аналогичным BDE-компонентам, а также к документации по IBX.
Итак, поместите на форму следующие компоненты:
IBDataSetl: TIBDataSet;
DataSourcel: TdataSource
DBGridl: TDBGrid
Необходимо указать свойства Database и Transaction у IBDataSetl, задать DataSourcel.DataSet равным IBDataSetl, а также указать DBGridl.DataSource равным DataSourcel.
Теперь необходимо указать тот запрос, который мы хотим выполнить, в свойстве SelectSQL у IBDataSetl (рис. 2.7).
Рис 2.7. Редактор свойства SelectSQL
Теперь мы можем открыть запрос прямо в design-time, задав свойство Active в True. Результат наших действий приведен на рис. 2.8.
Рис 2.8. Открытие запроса в IBDataSet1
Чтобы получить то же самое во время выполнения программы, напишите следующий обработчик события OnFormCreate у основной формы приложения'
procedure TForml.FormCreate(Sender: TObject);
begin
IBDatabasel.Open;
IBDataSetl.Open;
end;
He забудьте закрыть подключение к базе данных перед сохранением проекта, иначе попытка IBDatabase I .Open вызовет ошибку. Вы также можете написать этот код иначе: IBDatabasel Connected := True; IBDataSetl.Active := True. Он не вызовет сообщения об ошибке, если IBDatabasel и IBDataSetl были активны в design-time.
Данная глава не претендует на
Данная глава не претендует на звание учебника по IBX, поскольку дает лишь самые основные факты и описывает только наиболее важные, как нам кажется, особенности компонентов. Однако мы надеемся, что этот материал даст вам необходимый оазис для дальнейшего самосостоятельного изучения.
Также заметим, что в главе по FTBPlus вы сможете найти многие вещи, которые окажутся полезными и при работе с ШХ. Например, вы вполне сможете использовать материалы, описывающие работу с генератором отчетов FastReport, работу с BLOB-полями, локальную фильтрацию и обработку событий (event alerts).
