Вход

Работа с базами данных в Borland C++ Builder

Реферат* по программированию
Дата добавления: 20 июня 2006
Язык реферата: Русский
Word, rtf, 1.9 Мб
Реферат можно скачать бесплатно
Скачать
Данная работа не подходит - план Б:
Создаете заказ
Выбираете исполнителя
Готовый результат
Исполнители предлагают свои условия
Автор работает
Заказать
Не подходит данная работа?
Вы можете заказать написание любой учебной работы на любую тему.
Заказать новую работу
* Данная работа не является научным трудом, не является выпускной квалификационной работой и представляет собой результат обработки, структурирования и форматирования собранной информации, предназначенной для использования в качестве источника материала при самостоятельной подготовки учебных работ.
Очень похожие работы



Работа с базами данных в Borland C++ Builder

Содержание

  • Введение

  • Компонент TDataSource

  • Компонент TTable

  • Компонент TField

  • Компонент TDBGrid

  • Пример 1. Разработка простейшего приложения

  • Пример 2. Разработка приложения, использующего вычисляемое поле

  • Компоненты TDBLookup

  • Пример 3. Разработка приложения, использующего компонент просмотра баз данных

Введение

Используя Borland C++ Builder, можно создать приложения, работающие как с однопользовательскими базами данных (БД), так и с серверными СУБД, такими как Oracle, Sybase, Informix, Interbase, MS SQL Server, DB2, а также с ODBC-источниками. Возможности C++ Builder, связанные с созданием приложений, использующих базы данных, весьма обширны для того, чтобы описать их в одной статье. Поэтому сегодня мы рассмотрим лишь простейшие возможности работы с таблицами баз данных.

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

Набор данных в C++ Builder является потомком абстрактного класса TDataSet (абстрактный класс - это класс, от которого можно порождать другие классы, но нельзя создать экземпляр объекта данного класса). Например, классы TQuery, TTable и TStoredProc, содержащиеся на странице палитры компонентов Data Access, - наследники TDBDataSet, который, в свою очередь, является наследником TDataSet. TDataSet содержит абстракции, необходимые для непосредственного управления таблицами или запросами, обеспечивая средства для того, чтобы открыть таблицу или выполнить запрос и перемещаться по строкам.

Компонент TDataSource

Компонент DataSource действует как посредник между компонентами TDataSet (TTable, TQuery, TStoredProc) и компонентами Data Controls - элементами управления, обеспечивающими представление данных на форме. Компоненты TDataSet управляют связями с библиотекой Borland Database Engine (BDE), а компонент DataSource управляет связями с данными в компонентах Data Controls.

В типичных приложениях БД компонент DataSource, как правило, связан с одним компоненом TDataSet (TTable или TQuery) и с одним или более компонентами Data Controls (такими, как DBGrid, DBEdit и др.). Связь этого компонента с компонентами TDataSet и DataControls осуществляется с использованием следующих свойств и событий:

  • Cвойство DataSet компонента DataSource идентифицирует имя компонента TDataSet. Можно присвоить значение свойству DataSet на этапе выполнения или с помощью инспектора объектов на этапе проектирования.

  • Cвойство Enabled компонента DataSource активизирует или останавливает взаимосвязь между компонентами TDataSource и Data Controls. Если значение свойства Enabled равно true, то компоненты Data Controls, связанные с TDataSource, воспринимают изменения набора данных. Использование свойства Enabled позволяет временно разъединять визуальные компоненты Data Controls и TDataSource, например, для того, чтобы в случае поиска в таблице с большим количеством записей не отображать на экране пролистывание всей таблицы.

  • Свойство AutoEdit компонента DataSource контролирует, как инициируется редактирование в компонентах Data Controls. Если значение свойства AutoEdit равно true, то режим редактирования начинается непосредственно при получении фокуса компонентом Data Controls, связанным с данным компонентом TDataSet. В противном случае режим редактирования начинается, когда вызывается метод Edit компонента TDataSet, например, после нажатия пользователем кнопки Edit на компоненте DBNavigator. · Событие OnDataChange компонента DataSource наступает, когда происходит изменение значения поля, записи, таблицы, запроса.

  • Cобытие OnUpdateData компонента DataSource наступает, когда пользователь пытается изменить текущую запись в TDataSet. Обработчик этого события следует создавать, когда требуется соблюсти условия ссылочной целостности или ограничения, накладываемые на значения полей изменяемой базы данных.

Компонент TTable

Наиболее простым способом обращения к таблицам баз данных является использование компонента TTable, предоставляющего доступ к одной таблице. Для этой цели наиболее часто используются следующие свойства:

  • Active - указывает, открыта (true) или нет (false) данная таблица.

  • DatabaseName - имя каталога, содержащего искомую таблицу, либо псевдоним (alias) удаленной БД (псевдонимы устанавливаются с помощью утилиты конфигурации BDE, описание которой присутствует во многих источниках, посвященных продуктам Borland, либо с помощью SQL Explorer, вызываемого с помощью пункта меню Database/Explore). Это свойство может быть изменено только в случае, если таблица закрыта (ее свойство Active равно false), например:

Table1->Active = false;
Table1->DatabaseName = "BCDEMOS"
Table1->Active = true;

  • TableName - имя таблицы.

  • Exclusive - если это свойство принимает значение true, то никакой другой пользователь не может открыть таблицу, если она открыта данным приложением. Если это свойство равно false (значение по умолчанию), то другие пользователи могут открывать эту таблицу.

  • IndexName - идентифицирует вторичный индекс для таблицы. Это свойство нельзя изменить, пока таблица открыта.

  • MasterFields - определяет имя поля для создания связи с другой таблицей.

  • MasterSource - имя компонента TDataSource, с помощью которого TTable будет получать данные из связанной таблицы.

  • ReadOnly - если это свойство равно true, таблица открыта в режиме "только для чтения". Нельзя изменить свойство ReadOnly, пока таблица открыта.

  • Eof, Bof - эти свойства принимают значение true, когда указатель текущей записи расположен на последней или соответственно первой записи таблицы.

  • Fields - массив объектов TField. Используя это свойство, можно обращаться к полям по номеру, что удобно, когда заранее неизвестна структура таблицы:

Edit1->Text=Table1->Fields[2]->AsString;

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

  • Open и Close устанавливают значения свойства Active равными True и False соответственно.

  • Refresh позволяет заново считать набор данных из БД.

  • First, Last, Next, Prior перемещают указатель текущей записи на первую, последнюю, следующую и предыдущую записи соответственно, например:

Table1->First();
while (!Table1->Eof)
{
//что-то делаем...
Table1->Next();
};

  • MoveBy перемещает указатель на указанное число строк (оно может быть и отрицательным) в пределах таблицы

  • Insert, Edit, Delete, Append - переводят таблицу в режимы вставки записи, редактирования, удаления, добавления записи соответственно.

  • Post - осуществляет физическое сохранение измененных данных. Например:

Table2->Insert();
Table2->Fields[0]->AsInteger = 100;
Table2->Fields[1]->AsString =Edit1->Text;
Table2->Post();

  • Cancel - отменяет внесенные изменения, не сохраненные физически.

  • FieldByName - предоставляет возможность обращения к данным в полях по имени поля:

S=Table1->FieldByName("area")->AsString;

  • SetKey переключает таблицу в режим поиска.

  • GotoKey начинает поиск строки, значение Fields[n] которой равно выбранному, где n - номер колонки таблицы, начиная с 0:

Table1->SetKey();
Table1->Fields[0]->AsString=Edit1->Text;
Table1->GotoKey();

  • SetRangeStart, SetRangeEnd, ApplyRange позволяют выбрать нужные строки на основе диапазона значений какого-либо поля.

Table1->SetRangeStart();
Table1->Fields[0]->AsString = Edit1->Text;
Table1->SetRangeEnd();
Table1->Fields[0]->AsString = Edit2->Text;
Table1->ApplyRange();

  • FreeBookmark, GetBookmark, GotoBookmark- позволяют создать помеченную строку в таблице и затем вернуться к ней позже. Методы Bookmark используют класс TBookmark. Метод GetBookmark устанавливает закладку на текущей cтроке таблицы. GotoBookmark осуществляет перемещение в таблице к строке, ранее отмеченной закладкой. Метод FreeBookmark используется для уничтожения объекта типа TBookmark:

TBookmark Marker =Table1->GetBookmark();
Table1->GotoBookmark(Marker);
Table1->FreeBookmark(Marker);

Cобытия компонента TTable позволяют строить и контролировать поведение приложе ий БД. Например, событие BeforePost наступает перед вставкой или изменением записи, событие AfterPost - после сохранения вставленной или измененной записи, событие AfterDelete - после удаления записи и т.д.

Чтобы внести компонент TTable в форму, нужно выполнить следующее:

1. Используя страницу Data Access палитры компонентов, разместить компонент TTable на форме или в модуле данных.

2. Свойству DatabaseName присвоить имя каталога, где находится БД, либо псевдо има БД.

3. Свойству TableName присвоить имя таблицы или выбрать таблицу из выпадающего списка.

4. Внести в форму компонент DataSource и установить значение свойства DataSet равным имени компонента TTable.

5. Внести компоненты Data Controls и связать их с компонентом DataSource для того, чтобы отобразить на экране данные из таблицы БД.

Компонент TField

Объекты класса TField являются свойством объекта TDataSet (напомним, что некоторые свойства объектов сами являются объектами с их собственными наборами свойств, и TField - один из них).

Свойство Fields объекта типа TDataSet позволяет обращаться к отдельным полям набора данных. Свойство Fields является массивом или набором объектов TField, динамически создающимся во время выполнения приложения. Элементы массива соответствуют колонкам таблицы.

Объект TField не делает никаких предположений относительно типов данных, с которыми он связан. Он имеет несколько свойств, позволяющих установить или вернуть обратно значения поля, например, AsString, AsBoolean, AsFloat, AsInteger. Наиболее часто используются свойства Text (cтрока текста, выводимого в связанный с данным полем интерфейсный элемент) и FieldName (имя поля базы данных).

Fields Editor позволяет создать так называемый статический список полей таблицы, добавляемых к описанию класса формы. Когда впервые используются такие компоненты TDataSet, как компонент TTable или TQuery, список полей для них динамически генерируется в процессе выполнения приложения на основе имеющихся столбцов таблиц или результатов SQL-запроса. Fields Editor позволяет определить и затем модифицировать статический список компонентов Field на этапе проектирования приложения. При внесении колонок с использованием Fields Editor для каждого из полей, добавленных к TDataSet, возникают объекты TField, после чего можно увидеть эти поля в инспекторе объектов и использовать в приложениях их свойства, события и методы.

Использовать Fields Editor нужно следующим образом:

  1. Разместить компонент TTable или TQuery на форме.

  2. Установить свойство DatabaseName для TTable или TQuery.

  3. Установить свойство TableName компонента TTable или свойство SQL компонента TQuery.

  4. Выбрать компонент TDataSet на форме и нажать правую клавишу мыши, после чего появится контекстное меню.

  5. Из контекстного меню выбрать Fields Еditor. Появится пустое окно с заголовком, совпадающим с именем компонента TTable.

  6. Снова нажать правую клавишу мыши над пустым окном и из контекстного меню выб ать опцию Add Fields.

Имена всех колонок таблицы или запроса появятся в диалоговой панели Add Fields (рис. 1.)


Рис.1. Формирование списка полей

  1. Выбрать поля, которые нужно внести в список объектов, и нажать OK.


Рис. 2. Сформированный список полей, доступных на этапе проектирования

  1. Если требуется создать вычисляемое поле на основе имеющихся полей, нажать правую клавишу мыши и из контекстного меню выбрать New Field для создания нового поля на основе существующего или для создания вычисляемого поля (в дальнейшем следует создать код обработчика события OnCalcFields компонента TTable, где и производятся необходимые вычисления).

  2. Если необходимо удалить статическое поле из списка полей в наборе данных, нужно нажать правую клавишу мыши и из контекстного меню выбрать Delete.

После того, как в Fields Editor добавлены поля, они появятся в инспекторе объектов, а ссылки на них - в h-файле формы.

Если теперь применить операцию drag-and-drop к выделенным в Fields Editor полям, перенеся их на форму, то можно получить готовую форму с необходимым набором интерфейсных элементов (в нашем случае - DBEdit, позволяющий отображать и редактировать строковые, числовые, денежные и другие поля, чьи значения представимы в виде строки символов, и DBImage, позволяющий отображать графические поля и использовать Clipboard для их редактирования). Если к такой форме добавить компонент TDBNavigator (этот компонент реализует основные методы TTable и TQuery, связанные с редактированием данных) и связать его с имеющимся компонентом TDataSource, а затем скомпилировать проект, получим приложение для просмотра и редактирования данных в таблице.


Рис. 3. Результат переноса на форму полей из Fields Editor

При работе Fields Editor создаются объекты, соответствующие видимым в инспекторе объектов полям. Эти объекты являются потомками объектного типа TField. Таблица 1 описывает существующие классы таких объектов:

Таблица 1. Потомки TField

Потомок

Описание

TStringField

Текстовые данные фиксированной длины до 8192 символов.

TAutoIncField

Целые числа от -2,147,483,648 до 2,147,483,647. Предназначен для нумерации ст ок в наборе данных. Потомок TIntegerField.

TIntegerField

Целые числа от -2,147,483,648 до 2,147,483,647.

TSmallIntField

Целые числа от -32768 до 32767.

TWordField

Целые числа от 0 до 65535.

TFloatField

Действительные числа с абсолютной величиной от 1.2x10e-324 до 1.7x10e308 с точностью до 15-16 цифры.

TCurrencyField

Действительные числа с абсолютной величиной от 1.2x10e-324 до 1.7x10e308 с точностью до 15-16 цифры.

TBooleanField

Значения true или false.

TDateTimeField

Значения даты и времени.

TDateField

Значения даты.

TTimeField

Значения времени.

TBlobField

Произвольное поле данных без ограничений размера.

TBytesField

Произвольное поле данных без ограничений размера.

TVarBytesField

Произвольное поле данных до 65535 символов с фактической длиной, представленной в первых двух байтах.

TMemoField

Текст произвольной длины.

TGraphicField

Графическое поле произвольной длины, например, битовый массив.

Компонент TDBGrid

Компонент TDBGrid обеспечивает табличный способ отображения на экране строк данных из компонентов TTable или TQuery. Приложение может использовать TDBGrid для отображения, вставки, уничтожения, редактирования данных БД. Обычно DBGrid используется в сочетании с DBNavigator, хотя можно использовать и другие интерфейсные элементы, включив в их обработчики событий методы First, Last, Next, Ptior, Insert, Delete, Edit, Append, Post, Cancel компонента TTable.

Внешний вид таблицы (например, надписи в заголовках столбцов) может быть изменен с помощью редактора свойств Columns Editor. Для вызова Columns Editor нужно либо выбрать соответствующую опцию в контекстном меню компонента DBGrid или щелкнуть мышью в колонке значений напротив свойства Columns в инспекторе объектов.


Рис. 4. Установка свойств столбцов DBGrid с помощью Columns Editor

Вторым способом получения контроля над характеристиками DBGrid или другими компонентами является создание описанным выше способом статического набора компонентов TField. Имея компонент типа TField, созданный для каждого из полей в наборе данных, можно установить ширину, формат, маску, расположение, метку для отображения в DBGrid и другие характеристики.

Поля Float, Integer и Date обладают свойством DisplayMask. Это свойство можно использовать, чтобы форматировать данные в компоненте DBGrid или другом компоненте Data Controls. Например, экранный формат mm-dd-yy может использоваться для размещения полей типа дата.

Некоторые компоненты TField (например, TStringField) обладают свойством EditMask, которое можно установить, вводя данные в DBGrid и другие компоненты Data Controls. Для установки свойства EditMask нужно установить компонент Field в Object Inspector и выбрать свойство EditMask, после чего появится диалоговая панель Input Mask Editor, представленная на рис. 5.19. Чтобы проверить маску редактирования, нужно ввести значение в поле Test Input.


Рис. 5. Диалоговая панель Input Mask Editor

Пример 1. Разработка простейшего приложения

Попробуем создать простейшее приложение для редактирования таблицы БД. Для этого воспользуемся таблицей COUNTRY базы данных BCDEMOS, содержащейся в комплекте поставки C++ Builder.

Создадим новый проект и сохраним его главную форму как COUNT1.CPP, а сам проект как COUNT.MAK. Используя страницу Data Access палитры компонентов, разместим компоненты TTable и DataSource на форме. Установим свойство Database Name компонента Table1 равным BCDEMOS, свойство TableName равным COUNTRY.DB, а свойство Active равным true. Далее установим значение свойства DataSet компонента DataSource1 равным Table1.

Используя страницу Data Controls палитры компонентов, внесем компоненты DBGrid и DBNavigator в форму. Присвоим свойству DataSource обоих компонентов значение DataSource1.


Рис. 6. Главная форма приложения COUNT

Полученный проект можно скомпилировать и протестировать.

Отметим, что есть и более простой способ построить подобное приложение. Для этой цели можно воспользоваться утилитой SQL Explorer, вызываемой с помощью пункта меню Database/Explore. Выбрав страницу Databases в левой части окна SQL Explorer и щелкнув на значке "+" возле имени соответствующей базы данных, нужно выбрать опцию Tables. Затем в правой части окна нужно выбрать закладку Summary и перетащить с помощью мыши значок с именем нужной таблицы (в нашем случае COUNTRY.DB) на пустую форму. На форме появятся компоненты TDBGrid, TDataSource и TTable. После этого следует добавить DBNavigator, связать его с TDataSource и сделать таблицу активной.


Рис. 7. SQL Explorer

Пример 2. Разработка приложения, использующего вычисляемое поле

Таблица, используемая в предыдущем примере, содержит поля Area (площадь в кв.км ) и Population (население). Попробуем создать вычисляемое поле, содержащее п отность населения стран, представленных в этой таблице. Для этого запустим Fields Editor для компонента Table1, внесем все поля этой таблицы в набор данных и создадим новое поле с названием pop2. Выберем Float в списке Field type. Убедимся, что выбрана радиокнопка Calculated, и щелкнем на кнопке OK


Рис. 8. Создание вычисляемого поля

Создадим обработчик события OnCalcFields компонента TTable:

Table1pop2->Value=Table1Population->Value/Table1Area->Value;

Установим значение свойства DisplayFormat компонента Table1Pop2 равным .## . Запустим и протестируем приложение и убедимся в том, что вычисляемое поле действительно присутствует.

Компоненты TDBLookup

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

C++ Builder предоставляет четыре компонента для просмотра и ввода значений в таблицы:

  • Компонент TDBLookupListBox (страница Data Controls)

  • Компонент TDBLookupComboBox(страница Data Controls)

  • Компонент TDBLookupList (страница Win 3.1)

  • Компонент TDBLookupCombo(страница Win 3.1)

Последние два компонента присутствуют в палитре компонентов с целью совместимости с формами, созданными в версии Delphi 1.0 (как известно, в C++ Builder можно использовать формы Delphi 1.0 и 2.0).

Компоненты DBLookupList и DBLookupListBox являются похожими на ListBox компонентами, созданными для просмотра значения в одной таблице, основанного на значении в другой таблице. DBLookupList и DBLookupListBox содержат конечный набор значений. Когда DBLookupList и DBLookupListBox используются для ввода данных, пользователь должен выбрать один вариант из списка. DBLookupList и DBLookupListBox позволяют вывести на экран набор вариантов, основанных на значении в другой таблице.

Компоненты DBLookupList и DBLookupListBox отличаются от компонента DBListBox тем, что позволяют согласовать выбранное значение из списка с текущей строкой другой таблицы БД, тогда как для DBListBox список значений для выбора определен заранее и не имеет отношения к таблицам БД.

Компоненты DBLookupCombo и DBLookupComboBox являются похожими на ComboBox компонентами, то есть они похожи на DBLookupList и DBLookupListBox, за исключением того, что пользователь может либо выбирать значение в списке, либо вводить новое значение. ComboBox, на который похожи DBLookupCombo и DBLookupComboBox, сочетает в себе возможности ListBox с возможностями компонента Edit. DBLookupCombo и DBLookupComboBox отличаются от компонента ComboBox тем, что позволяют согласовать выбранное значение с текущей строкой другой таблицы БД. При размещении компонентов DBLookupList, DBLookupListBox, DBLookupCombo или DBLookupComboBox на форме эта форма в приложении должна содержать DataSource и компонент - потомок TDataSet (например, TTable).

Пример 3. Разработка приложения, использующего компонент просмотра баз данных

В этом примере рассматривается связь таблиц CUSTOMER (компании-заказчики) и ORDERS (их заказы) из базы данных BCDEMOS и используется компонент DBLookupListBox для того, чтобы отобразить на экране имя компании, соответствующее значению CustID, находящемуся в таблице ORDERS.

Чтобы создать форму для выведения на экран выбранных из таблицы ORDERS полей, следует открыть новый проект и сохранить главную форму как DBLOOK1.CPP, а проект как DBLOOK.MAK. Далее нужно разместить на форме компоненты TTable, DataSource, DBGrid и DBNavigator. Далее следует присвоить свойству Database Name компонента Table1 значение BСDEMOS, свойству TableName - значение ORDERS.DB, а свойству Active - значение true. Свойству DataSet компонента DataSource1 присвоим значение Table1, а свойству AutoEdit - значение false. Свойству DataSource компонентов DBGrid1 и DBNavigator1 присвоим значение DataSource1. Далее используем Fields Editor, чтобы внести в набор данных Table1 поля OrderNo, CustNo, SaleDate, ItemsTotal, AmountPaid. Расположим поля в Fields Editor так, чтобы OrderNo был бы первым, а CustNo - вторым. Можно скомпилировать и сохранить это приложение, затем запустить и протестировать его.

Теперь внесем в приложение компонент DBLookupListBox и установим его свойство DataSource равным DataSource1, а свойство DataField равным CustNo. Поместим на форму новые компоненты TTable и DataSource. Установим свойство DatabaseName для компонента Table2 равным BCDEMOS, свойство TableName равным CUSTOMER.DB, а свойство Active равным true. Свяжем DataSource2 с Table2. Свяжем компонент DBLookupListBox1 с DataSource2, установив значение свойства ListSource компонента DBLookupListBox1 равным DataSource2, свойства KeytField равным CustNo, а свойства ListField равным Company. Можно скомпилировать и сохранить приложение, затем запустить и протестировать его.

В компоненте DBLookupListBox будет выделено название компании, соответствующее значению CustNo в текущей строке DBGrid (рис. 9). Можно использовать DBLookupListBox для выбора заказчика по имени, при этом в таблице Orders будет устанавливаться соответствующее значение CustNo.


Рис. 9. Приложение с компонентом DBLookupListBox.

В следующих статьях будет рассмотрено использование компонента TQuery и возможности создания и использования SQL-запросов в приложениях С++ Builder.











+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++








Работа с базами данных в Borland C++ Builder

Наталия Елманова

Содержание

  • Введение

  • Компонент TQuery

  • Visual Query Builder

  • Пример использования компонента TQuery

  • Модули данных

  • SQL Explorer и словарь данных

Введение

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

Запрос в C++ Builder - это объект, представляющий собой набор данных. Обычно для создания запроса используется компонент TQuery - потомок абстрактного класса TDataSet.

Компонент TQuery

Компонент TQuery, как и компонент TTable, обладает всеми свойствами компонента TDataSet.

Как и в случае с компонентом TTable, компонент TDataSource управляет взаимодействием между компонентами Data Controls и компонентом TQuery. Обычно приложение имеет один компонент DataSource для каждого компонента TQuery.

Наиболее часто используются следующие свойства компонента TQuery:

  • Active - указывает, открыт (true) или закрыт (false) данный запрос

  • Eof, Bof - эти свойства принимают значение true, когда указатель текущей записи расположен на последней или соответственно первой строке набора данных, являющегося результатом выполнения запроса.

  • DatabaseName - имя каталога либо псевдоним (alias) удаленной БД, к которой осуществляется запрос.

  • DataSource - указывает источник данных для параметризованных запросов (т.е. запросов с параметрами, значение которых заранее неизвестно).

  • Fields - это свойство доступно только во время выполнения (run-time only) и используется для чтения или модификации поля, определяемого по порядковому номеру.

  • Params - содержит параметры для параметризованного запроса, как SomeNo в следующем примере:

Select * from Orders where CustNo=:SomeNo

  • SQL - строковый массив, содержащий текст оператора запроса SQL.

Отметим, что язык запросов SQL (Structured Query Language), традиционно применяемый при работе с серверными СУБД, может быть использован и при работе с таблицами формата dBase и Paradox. Не вдаваясь в подробное описание синтаксиса этого языка (с ним можно познакомиться в других источниках, например, в книге М.Грабера "Введение в SQL"), отметим одну его особенность. SQL – язык непроцедурный. На нем можно написать, что нужно получить в результате запроса, но нельзя написать, как это сделать, то есть нельзя описать саму процедуру выполнения запроса. Дело в том, что реализация выполнения тех или иных операторов SQL серверами баз данных может быть различна, и в большинстве случаев неинтересна клиентскому приложению, создаваемому с помощью С++ Builder. В случае таблиц dBase или Paradox реализацию SQL берет на себя библиотека Borland Database Engine.

Компонент TQuery позволяет использовать операторы SQL для того, чтобы определять или создавать наборы данных, которые можно отобразить на экране, вставлять, удалять и редактировать строки.

  • RequestLive - если это свойство имеет значение true и синтаксис запроса таков, что его результат может быть модифицируем, пользователь может редактировать данные с сохранением их в базе данных. Если RequestLive имеет значение false, результат запроса возвращается в состоянии read-only.

Наиболее часто используются следующие методы компонента TQuery:

  • ExecSQL - выполняет SQL-запрос, содержащийся в свойстве SQL, если запрос не возвращает данные. Следует употреблять этот метод при вставке, редактировании или удалении данных. При выполнении же оператора SELECT (выбор данных) следует использовать метод Open. Следующий пример показывает применение метода ExecSQL:

Query1->Close();
Query1->SQL->Clear();
Query1->SQL->Add("Delete emp where empno=1010");
Query1->ExecSQL();

  • Open - открывает компонент TQuery. Он эквивалентен присвоению свойству Active значения true. Используется, если результатом запроса является набор данных (такие запросы обычно начинаются с оператора SELECT). Пример использования метода Open:

Query1->Open();

  • Close - закрывает компонент TQuery. Вызов Close эквивалентен присвоению свойству Active значения false. Пример использования метода Close:

Query1->Close();

  • Prepare - обеспечивает передачу серверу баз данных запроса, содержащегося в свойстве SQL, для оптимизации и компиляции. Полный запрос с параметрами не передается, пока не вызваны методы Open или ExecSQL. Даже если метод Prepare не вызывается явно, он будет вызван неявно, если используются методы Open или ExecSQL (в этом можно убедиться, запустив утилиту SQL Monitor). Пример использования метода Prepare:

Query1->Close();
Query1->SQL->Add("Delete emp where empno=:empno");
Query1->Prepare();

Компоненты TQuery обладают большим разнообразием методов, унаследованных от TDataSet. Наиболее часто используются следующие методы:

  • First, Last, Next, Prior перемещают указатель текущей записи на первую, последнюю, следующую и предыдущую записи соответственно, например:

  • MoveBy перемещает указатель на определенное количество строк.

  • Insert, Edit, Delete, Append, Post, Cancel - позволяют модифицировать результат запроса. Метод Insert позволяет вносить в результат запроса строки, как в следующем примере:

Query2->Insert();
Query2->Fields[0]->AsInteger = 100;
Query2->Fields[1]->AsString =Edit1->Text;
Query2->Post();

Метод Post подтвержает операции Insert, Update или Delete, совершая реальное физическое изменение в базе данных. Метод Cancel отменяет незавершенные операции Insert, Delete, Edit или Append.

  • FreeBookmark, GetBookmark, GotoBookmark- - позволяют создавать закладки (маркированные строки) в запросе и затем вернуться к такой строке позже.

Прежде чем перейти к непосредственному использованию запросов, следует остановиться на весьма полезном инструменте - генераторе запросов Visual Query Builder, с помощью которого можно определить свойство SQL компонента TQuery, если по каким-либо причинам это неудобно делать непосредственно в редакторе свойств.

Visual Query Builder

Visual Query Builder (VQB) является визуальным средством для построения запросов, базирующихся на SQL. С помощью этого средства можно строить комплексные запросы, обладая некоторыми знаниями SQL или не имея таких знаний вовсе. Запросы строятся шаг за шагом путем последовательного добавления выражений, таблиц, полей и отношений, пока не получится требуемый результат.

Visual Query Builder можно вызвать, выбирая компонент TQuery и нажимая правую кнопку мыши, после чего появляется контекстное меню, из которого следует выбрать опцию Query Builder.

Примечание. Visual Query Builder входит в комплект поставки не всех версий Borland C++ Builder либо может быть не установлен. В этом случае в контекстном меню может не быть соответствующей опции.

После выбора Query Builder на экране появится диалоговая панель Databases, позволяющая выбрать БД и осуществить соединение с ней (рис. 1).


Рис. 1. Выбор псевдонима базы данных

После соединения с базой данных на экран выводится окно Visual Query Builder и диалоговая панель для выбора таблиц, используемых в запросе (рис. 2).


Рис.2. После соединения с БД появляется окно Visual Query Builder и диалоговая панель Add Table.

Панель инструментов Visual Query Builder позволяет выбирать операции, которые можно выполнить при создании, тестировании и просмотре текста запроса. Таблица 8.1 описывает назначения кнопок на панели инструментов Visual Query Builder:

Таблица 1. Панель инструментов Visual Query Builder

Кнопка

Назначение



New

Создает новый запрос.



Open

Открывает файл запроса.



Save As

Сохраняет запрос в файле.



Options

Помещает на экране диалоговую панель Options, позволяющую установить различные опции запроса.



Table

Помещает на экран диалоговую панель Add Table, позволяющую вносить таблицы в оператор SQL.



Expression

Помещает на экран диалоговую панель Expression, позволяющую создавать вычисляемые поля, допустимые с точки зрения языка SQL.



SQL

Выводит окно с текстом сгенерированного SQL-запроса.



Run

Выполняет сгенерированный запрос и выводит на экран результаты.



OK

Устанавливает свойство SQL компонента TQuery равным сгенерированному запросу и закрывает Visual Query Builder.



Cancel

Отменяет присвоение свойства SQL компонента TQuery и закрывает Visual Query Builder.



Help

Выводит на экран оперативную помощь для Visual Query Builder.

Диалоговая панель Add Table (рис. 2) появляется при открытии Visual Query Builder или при выборе соответствующей кнопки диалоговой панели. Она позволяет вносить в запрос таблицы, выводя список всех таблиц в текущей БД. Если отметить опцию Include System Tables, для построения запроса будут доступны системные таблицы данной БД.


Рис. 3. В рабочем пространстве окна Visual Query Builder появится таблица, выбранная из списка

Для внесения одной или более таблиц в запрос следует выполнить следующее:

1.Если диалоговая панель Add Table не присутствует на экране, щелкнуть кнопкой Table на панели инструментов, чтобы вывести ее на экран.

2. Выбрать имя таблицы из списка таблиц в диалоговой панели и щелкнуть на кнопке Add. Описание структуры выбранной таблицы появится в верхней части окна окна Visual Query Builder.

3. Повторить п.2, пока все требуемые таблицы не будут внесены в запрос, и затем нажать кнопку Close.

Чтобы внести колонку одной из таблиц в запрос, нужно выбрать имя колонки и затем перетащить эту колонку и поместить ее на таблицу в нижней части окна, либо дважды щелкнуть на имени колонки. Для выбора всех полей таблицы следует перетащить в нижнюю часть окна значок * , находящийся над списком полей таблицы.


Рис. 4. Создание комбинированного запроса

Чтобы скомбинировать информацию из нескольких таблиц, нужно определить, как будут соединяться разные таблицы. С помощью Visual Query Builder можно определить колонки, имена которых служат для связи таблиц. С этой целью нужно выбрать имя колонки, по которой осуществляется межтабличная связь, в одной из связываемых таблиц, нажать левую клавишу мыши и переместить курсор (он изменит форму) на имя соответствующей колонки другой таблицы. В результате в рабочем пространстве запроса образуется линия, связывающая колонки этих двух таблиц (рис. 8.7).

Можно просмотреть или отредактировать критерий соединения таблиц, два раза щелкнув на линии, показывающей это соединение в верхней части окна Visual Query Builder. При этом появляется диалоговый блок Join (рис.5):


Рис. 5. Выбор критерия соединения таблиц

Чтобы определить критерий отбора для запроса, нужно использовать строку Criteria таблицы в нижней части окна Visual Query Builder.

Строка Criteria допускает любые выражения запроса, являющиеся допустимыми с точки зрения предложения WHERE оператора SQL (табл. 2).

Таблица 2. Допустимые выражения в предложении WHERE SQL-запроса

Выражение

Описание

=

Равно

>

Больше, чем

<

Меньше, чем

!=

Не равно

like

Строка символов в сравнении с образцом.

Between

Не меньше, чем начальное значение и не больше, чем конечное.

In

Содержится в списке

Выражения, введенные в строку Criteria, являются условиями AND. Например, если имеется таблица с колонкой Name и требуется найти каждый элемент в этой колонке, начинающийся с буквы С, следует ввести в строку Criteria Name LIKE'C%'. Результат эквивалентен внесению AND Name LIKE 'C%'в предложение WHERE оператора SQL.

Условия OR вводятся как выражения в строку OR (ниже строки Criteria).

Можно отсортировать результаты в восходящем (ascending) или нисходящем (descending) порядке для выбранной колонки. Чтобы определить порядок сортировки для колонки, следует поместить указатель мыши на колонке около строки Sort , щелкнуть правой кнопкой мыши и выбрать Ascending или Descending из контекстного меню.

Можно сгруппировать результаты запроса, используя строку Option.

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


Рис. 6. Выбор опции для колонки

Можно определить условия для результатов группировки, используя строку Group Condition, что эквивалентно внесению выражения с предложением HAVING в SQL-операторе SELECT, использующем предложение GROUP BY.

Visual Query Builder позволяет определить выражения как часть запроса. Выражения представляют собой операции вычислений на основе числовых значений, строковые операции и т.д.

Чтобы создать вычисляемое поле, следует щелкнуть кнопкой Expression на панели инструментов. Появится диалоговая панель Expression ( см. рис. 7).


Рис. 7. Вызов диалоговой панели Expression .

Диалоговая панель Expression позволяет использовать в запросах арифметические операции умножения, деления, сложения, вычитания, имена колонок и составные выражения, такие как avg, count, min, max и sum. Можно редактировать вручную или строить выражения, используя блок редактора Expression.


Рис. 8. Диалоговая панель Options

Диалоговая панель Options (рис. 8) используется для того, чтобы определить опции для оператора SQL. Можно, например, удалить повторяющиеся записи (Remove Duplicate Records), использовав предложение DISTINCT оператора SQL. Чтобы вызвать диалоговую панель Options, нужно щелкнуть кнопкой Options на панели инструментов.

Можно выполнить запрос, сгенерированный Visual Query Builder. Результаты запроса отобразятся на экране в диалоговой панели Result Window (окно результатов). Это окно позволяет убедиться, что колонки запроса, критерий выбора, критерии группировки и сортировки были определены корректно. Чтобы выполнить запрос, нужно щелкнуть кнопкой Run на панели инструментов. Появится окно Result Window, подобное представленному на рис. 8.


Рис. 9. Результаты запроса отобразятся на экране в Result Window

Можно проверить текст запроса, просматривая окно SQL Statement, для чего следует щелкнуть на кнопке SQL на панели инструментов. Это окно показывает сгенерированный оператор SQL. При добавлении или изменении колонок запроса, критерия отбора, критерия группировки или сортировки содержимое окна SQL Statement редактируется автоматически (рис. 10).


Рис. 10. Сгенерированный оператор SQL в окне SQL Statement.

Для завершения работы Visual Query Builder следует нажать кнопку с зеленой галочкой на инструментальной панели. После этого свойству SQL компонента TQuery, для которого был активизирован Visual Query Builder, будет присвоен сгенерированный текст SQL-запроса.

Пример использования компонента TQuery

Попробуем применить полученные сведения для создания приложения, использующего компоненты TTable, TQuery, TDataSource, TDBGrid. Воспользуемся для этой цели таблицами Customer.db и Orders.db, имеющимися в базе данных BCDEMOS, входящей в комплект поставки Borland C++ Builder. Данное приложение должно будет выводить списки клиентов из таблицы Customer, их заказов из таблицы Orders, а также позволять выбирать диапазон номеров клиентов.

Создадим новый проект и сохраним его главную форму как CUST1.CPP, а проект как CUST.MAK.

Изменим заголовок заголовок формы на "Контроль заказов". Разместим на форме компонент TDBGrid, два компонента TGroupBox, один компонент TTable, два компонента TQuery, три компонента TDataSource. На компонент GroupBox1 поместим три компонента TRadioButton и два компонента TButton. На компонент GroupBox2 поместим два компонента TEdit, два компонента TEdit и один компонент TButton.


Рис. 11. Расположение компонентов на форме приложения CUST

Установим следующие свойства для этих компонентов:

Имя компонента

Свойство

Значение

Table1

DatabaseName

BCDEMOS


TableName

CUSTOMER.DB


Active

false

DataSource1

DataSet

Table1

DBGrid1

DataSource

DataSource1

Query1

Database Name

BCDEMOS


SQL

select * from orders


Active

false

DataSource2

DataSet

Query1

Query2

DatabaseName

BCDEMOS

DataSource3

DataSet

Query2

Button1

Caption

Открыть список &клиентов

Button2

Caption

Открыть список &заказов

RadioButton1

Caption

Клиенты


Checked

true

RadioButton2

Caption

Заказы

GroupBox1

Caption


GroupBox2

Caption


Button3

Caption

Установить &диапазон

Edit1

Text


Edit2

Text


Label1

Caption

Начало:

Label2

Caption

Конец:

RadioButton3

Caption

Заказы клиентов

Создадим обработчик события OnClick для кнопки Button1:

void __fastcall TForm1::Button1Click(TObject *Sender)
{
if (Table1->Active)
{
Table1->Close();
Button1->Caption = "Ioe?uou nienie &eeeaioia";
}
else
{
Table1->Open();
Button1->Caption= "Cae?uou nienie &eeeaioia";
}
}

Теперь при нажатии на эту кнопку таблица Customer будет то открываться, то закрываться, при этом будет изменяться и надпись на кнопке.

Создадим обработчик события OnClick для кнопки Button2:

void __fastcall TForm1::Button2Click(TObject *Sender)
{
if (Query1->Active)
{
Query1->Active = false;
Button2->Caption = "Ioe?uou список &caeacia";
}
else
{
Query1->Active = true;
Button2->Caption = "Заe?uou список &caeacia";
}
}

При нажатии на кнопку Button2 будет то открываться, то закрываться запрос Query1, содержащий список заказов:

Создадим обработчики событий OnClick для радиокнопок RadioButton1 и RadioButton2:

void __fastcall TForm1::RadioButton1Click(TObject *Sender)
{
DBGrid1->DataSource = DataSource1;
}
//---------------------------------------------------------------------------
void __fastcall TForm1::RadioButton2Click(TObject *Sender)
{
DBGrid1->DataSource =DataSource2;
}

Теперь с помощью этих радиокнопок можно переключаться между списком клиентов и списком заказов.

Создадим обработчик события OnClick для кнопки Button3:

void __fastcall TForm1::Button3Click(TObject *Sender)
{
if (Table1->Active)
{
Table1->SetRangeStart();
Table1->Fields[0]->AsString = Edit1->Text;
Table1->SetRangeEnd();
Table1->Fields[0]->AsString = Edit2->Text;
Table1->ApplyRange();
}
}

Теперь с помощью полей редактирования Edit1 и Edit2 и кнопки Button3 можно выбрать диапазон номеров клиентов для отображения сведений о них в DBGrid1.

Затем с помощью Visual Query Builder установим свойство SQL компонента Query2. Выберем в качестве имени базы данных BCDEMOS и внесем в запрос таблицы CUSTOMER и ORDERS. Затем установим связь между таблицами, проведя линию от поля CustNo в таблице CUSTOMER к полю CustNo в таблице ORDERS.

Внесем в запрос следующие поля:

  • Customer.CustNo

  • Customer.Company

  • Orders.OrderNo

  • Orders.AmountPaid


Рис. 12. Использование Visual Query Builder для создания комбинированного запроса

Теперь отсортируем результаты запроса по номеру покупателя и выйдем из Visual Query Builder.

Используя инспектор объектов, выберем компонент Query2 и установим его свойство Active равным true.

Создадим обработчик события OnClick для RadioButton3:.

void __fastcall TForm1::RadioButton3Click(TObject *Sender)
{
DBGrid1->DataSource= DataSource3;
}

Скомпилируем приложение. Щелкнем кнопками и "Открыть список заказов", чтобы открыть оба набора данных. Попробуем, используя радиокнопки, переключаться между ними.


Рис. 13. Так выглядит готовое приложение

Нажмем кнопку "Открыть список клиентов". Введем значения полей "Начало" и "Конец" (например, 1200 и 1700 соответственно) и затем нажмем кнопку "Установить диапазон". Убедимся, что значения номеров заказов действительно находятся в пределах этого диапазона.

Щелкнем на радиокнопке "Заказы клиентов" и убедимся, что результирующий набор данных действительно содержит сведения из обеих таблиц.

Модули данных

В предыдущем примере мы размещали компоненты со страницы Data Access непосредственно на главную форму приложения. Однако наличие на форме большого количества невидимых компонентов в ряде случаев затрудняет проектирование пользовательского интерфейса. Кроме того, нередко бывает удобно отделить компоненты, отвечающие за доступ к данным и бизнес-логику информационной системы, от интерфейсных элементов, например, для обегчения ее дальнейшей модернизации. Для этой цели в C++ Builder имеется специальный тип, называемый модулем данных - TDataModule. Компонент этого типа можно условно считать специальным видом формы, хотя он и порожден непосредственно от TСomponent. Такой компонент-контейнер может содержать компоненты со страницы Data Access, а сам он не виден пользователю во время выполнения.

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


Рис.14. Размещение компонентов доступа к данным в DataModule

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

//----------------------------------------------------
#include
#pragma hdrstop

#include "cust1.h"
#include "custdm1.h" // Ссылка на модуль данных
//-----------------------------------------------------
#pragma link "Grids"
#pragma resource "*.dfm"
TForm1 *Form1;
//-----------------------------------------------------
__fastcall TForm1::TForm1(TComponent* Owner): TForm(Owner)
{
}
//-----------------------------------------------------
void __fastcall TForm1::Button1Click(TObject *Sender)
{
if (DataModule1->Table1->Active)
{
DataModule1->Table1->Close();
Button1->Caption = "Открыть таблицу &клиентов";
}
else
{
DataModule1->Table1->Open();
Button1->Caption= "Закрыть таблицу &клиентов";
};
}
//-----------------------------------------------------
void __fastcall TForm1::Button2Click(TObject *Sender)
{
if (DataModule1->Query1->Active)
{
DataModule1->Query1->Active = false;
Button2->Caption = "Открыть таблицу &заказов";}
else

{
DataModule1->Query1->Active = true;
Button2->Caption = "Закрыть таблицу &заказов";
}
}
//-----------------------------------------------------
void __fastcall TForm1::RadioButton1Click(TObject *Sender)
{
DBGrid1->DataSource = DataModule1->DataSource1;
}
//-----------------------------------------------------
void __fastcall TForm1::RadioButton2Click(TObject *Sender)
{
DBGrid1->DataSource = DataModule1->DataSource2;
}
//-----------------------------------------------------
void __fastcall TForm1::RadioButton3Click(TObject *Sender)
{
DBGrid1->DataSource = DataModule1->DataSource3;
}
//----------------------------------------------------
void __fastcall TForm1::Button3Click(TObject *Sender)
{
if (DataModule1->Table1->Active)
{
DataModule1->Table1->SetRangeStart();
DataModule1->Table1->Fields[0]->AsString = Edit1->Text;
DataModule1->Table1->SetRangeEnd();
DataModule1->Table1->Fields[0]->AsString = Edit2->Text;
DataModule1->Table1->ApplyRange();
}
}
//----------------------------------------------------

SQL Explorer и словарь данных

SQL Explorer является удобным инструментом при работе с базами данных. Для его запуска следует выбрать пункт меню Database/Explore или запустить его в качестве отдельного приложения. В левой части окна Explorer на странице Databases представлены в виде раскрывающегося списка свойства всех описанных в файле конфигурации BDE псевдонимов. В правой части окна можно просмотреть содержимое таблиц, ввести и выполнить SQL-запрос к таблице, а также получить сведения о псевдонимах баз данных (драйвер БД, местоположение, используемый языковый драйвер и иные параметры, содержащиеся в файле конфигурации BDE), сведения о таблицах (тип таблицы, версия, дата последнего обновления и др.) и, при необходимости, внести в них изменения.



Рис. 15. SQL Explorer

Сам словарь данных доступен для просмотра на странице Dictionary. В нем в виде раскрывающегося списка содержатся сведения о базах данных и расширенных атрибутах полей таблиц (раздел Attribute Sets), в число которых входят, например, максимальное и минимальное значение для данного поля, значение по умолчанию, тип и класс контрольного элемента, метка при отображении на форме, маска редактирования и другие атрибуты, не содержащиеся непосредственно в таблицах, но характеризующие модель данных.


Рис.16. Просмотр и модификация словаря данных в SQL Explorer

Отметим, что пользователь может создавать свои словари данных (пункт меню Dictionary/New). По умолчанию словари данных создаются в виде таблиц формата Paradox, но не возбраняется хранить их в других форматах или на серверах баз данных (это имеет смысл при работе над крупными проектами).

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++


Настройка параметров доступа к данным в C++ Builder

Наталия Елманова

Содержание

  • Библиотека Borland Database Engine (BDE)

  • Утилита настройки BDE

  • Настройка драйверов баз данных

  • Создание и настройка псевдонимов баз данных

  • Системные настройки BDE

  • Настройка параметров отображения даты, времени и чисел

  • Немного о средствах языковой настройки BDE

  • Особенности настройки BDE для работы с некоторыми источниками данных

    • dBase

    • Paradox

    • ODBC-источники

    • Oracle

    • Interbase

Библиотека Borland Database Engine (BDE)

Если созданное с помощью С++ Builder приложение в процессе работы обращается к базам данных, оно, как правило, использует для этой цели библиотеку BDE (Borland Database Engine), основанную на технологии IDAPI (Integrated Database Application Program Interface). Эта библиотека устанавливается автоматически при установке С++ Builder. По умолчанию она устанавливается в каталог C:\Program Files\Borland\Common Files\BDE.

Следует отметить, что файлы, входящие в состав библиотеки BDE, предназначены для использования не только приложениями, созданными с помощью С++ Builder, но и многими другими продуктами Borland (Visual dBase, Paradox, Delphi, Borland C++, IntraBuilder), созданными на их основе приложениями, а также офисными приложениями Corel (например, электронной таблицей Quattro Pro), генератором отчетов Crystal Reports (Seagate Software) . Поэтому при наличии нескольких использующих BDE приложений все 32-разрядные приложения (в том числе C++ Builder) используют установленную последней 32-разрядную версию BDE. В этом случае по умолчанию программа установки C++ Builder предложит поставить BDE в каталог, где установлена уже используемая версия BDE.



Рис.1. Связь приложений с источниками данных с помощью BDE

BDE обеспечивает для созданных приложений:

  • непосредственный доступ к локальным базам данных (dBase, Paradox, текстовые файлы)

  • доступ к SQL-серверам (Oracle, Sybase, MS SQL Server, InterBase, Informix, DB2) с помощью драйверов Borland SQL Links

  • доступ к любым источникам данных, имеющим драйвер ODBC (Open DataBase Connectivity), например, к файлам электронных таблиц (Excel, Lotus 1-2-3), серверам баз данных, не имеющим драйверов SQL Links (например, Gupta/Centura)

  • создание приложений клиент-сервер, использующих разнородные данные

  • высокую производительность при работе с плоскими таблицами

  • использование SQL (Structured Query Language - язык запросов к серверным СУБД), в том числе при работе с локальными данными

  • изоляцию приложения от средств языковой поддержки

  • изоляцию приложения от конфигурации системы и сети

Утилита настройки BDE

При возникновении необходимости доступа к данным в большинстве случаев для их источника (как правило, это какая-либо конкретная база данных) создается псевдоним (alias), имя которого используется приложением. Параметры этого и других псевдонимов, а также параметры настройки драйверов баз данных содержатся в файле idapi32.cfg, расположенном в том же каталоге, что и файлы BDE. Для изменения содержания этого файла, а также значений соответствующих этой библиотеке ключей реестра Windows 95 и Windows NT используется утилита конфигурации BDE - BDECFG32.EXE.

Утилита конфигурации состоит из одной формы, содержащей блокнот из шести страниц.

Страница Drivers содержит параметры доступа к различным типам данных.

Страница Aliases содержит сведения о псевдонимах источников данных, к которым посредством BDE обращаются приложения, установленные на данном компьютере.

Страница System содержит параметры настройки работы самой библиотеки BDE, связанные с использованием памяти, сетевого окружения и других ресурсов, доступных использующим BDE приложениям. Эти параметры содержатся в реестре Windows 95 (или Windows NT).

Страницы Date, Time, Number содержат правила отображения в приложениях календарных дат, времени и числовых данных в соответствии с правилами, принятыми в той или иной стране.

Настройка драйверов баз данных

Для настройки драйверов баз данных используется страница Drivers утилиты настройки BDE. В левой части этой страницы имеется список доступных для BDE драйверов, куда входят драйверы для dBase и Paradox, установленные на данном компьютере драйверы SQL Links для доступа к серверным СУБД, а также имена ODBC-источников данных, созданные с помощью 32-разрядного администратора ODBC панели управления Windows (рис. 5.2).


Рис. 2. Настройка драйверов баз данных

При нажатии на кнопку New ODBC Driver можно добавить в список новый ODBC-источник данных (перед этим, естественно, следует установить соответствующий ODBC-драйвер и описать источник данных с помощью ODBC-администратора в панели управления Windows). Можно также удалить ODBC-драйвер из файла конфигурации BDE (Delete ODBC Driver).

В правой части страницы Drivers указаны параметры выбранного в списке драйвера. При настройке драйверов следует заменить параметры, указанные по умолчанию, на значения, специфические для выбранного источника данных (например, языковый драйвер, правила обработки запросов, имя сервера и базы данных, тип сетевого протокола для доступа к серверу, номер версии). Эти наборы параметров различны для различных драйверов баз данных .

Создание и настройка псевдонимов баз данных

Для доступа приложений к данным средства разработки Borland используют механизм псевдонимов, описывающих доступ к конкретным источникам данных. Создать описание нового источника данных можно, нажав кнопку New Alias в левой части окна (рис. 6.3, 6.4).


Рис. 3. Выбор псевдонима БД и установка параметров

После этого в появившейся диалоговой панели следует ввести имя-псевдоним для этого источника и выбрать нужный драйвер из предложенного списка (того, что определен на странице Drivers). Имя STANDARD в этом случае соответствует таблицам dBase, Paradox и текстовым файлам (в формате CSV - Comma Separated Value).


Рис. 4.Создание нового псевдонима БД

В правой части страницы Aliases содержатся параметры конкретных источников данных, которые можно модифицировать, заменяя значения по умолчанию (в том числе унаследованные с предыдущей страницы), например, имена каталогов, серверов, имя пользователя по умолчанию, языковый драйвер и др.

Системные настройки BDE

Страница системных настроек позволяет указать параметры системы и сети, используемые BDE и хранящиеся в реестре Windows (рис. 5, табл. 1).


Рис. 5. Страница System утилиты конфигурации BDE.

Таблица 1. Параметры системы и сети, используемые BDE.

Параметр

Описание

Значение по умолчанию

VERSION

версия BDE


LOCAL SHARE

Если этот параметр равен true, можно использовать одни и те же данные приложениями, использующими BDE, и приложениями, не использующими BDE

FALSE

MINBUFSIZE

Минимальный размер буфера оперативной памяти для кэширования данных из БД. Возможные значения - от 32 до 65535 Кб, но не более, чем объем доступной Windows оперативной памяти


MAXBUFSIZE

Максимальный размер буфера оперативной памяти для кэширования данных из БД. Должен быть выше, чем MINBUFSIZE, но не более, чем объем доступной Windows оперативной памяти. Должен быть кратен 128.

2048

LANGDRIVER

Языковый драйвер, соответствующий национальной версии операционной системы


MAXFILEHANDLES

Максимальное число файлов, открываемых BDE. Может принимать целые значения от 5 до 256

48

SYSFLAGS

Внутренний параметр BDE


LOW MEMORY USAGE LIMIT

Максимально допустимый объем основной памяти, используемый BDE

32

AUTO ODBC

если этот параметр принимает значение true, используются все ODBC-источники из файла ODBC.INI

FALSE

DEFAULT DRIVER

драйвер, используемый первым, если тип БД - FILE, и имя таблицы не имеет расширения.


SQLQRYMODE

Метод исполнения запросов к серверам. Может принимать значения NULL, SERVER, LOCAL

NULL

SHAREDMEMSIZE

Максимальный размер для разделяемой оперативной памяти

2048

SHAREDMEMLOCATION

Предпочтительный адрес для размещения разделяемой области памяти.

E000 (Windows 95) 7000(Windows NT)

Настройка параметров отображения даты, времени и чисел

Страница Date позволяет указать параметры отображения дат (см. табл.2).

Таблица 2. Параметры настройки отображения дат

Параметр

Описание

Значение по умолчанию

SEPARATOR

Символ-разделитель числа, месяца и года

Значение, содержащееся в настройках панели управления Windows 95/NT

MODE

Параметр, определяющий порядок следования числа. месяца и года. Может принимать значения: 0(MDY), 1( DMY), 2(YMD).

Значение, содержащееся в настройках панели управления Windows 95/NT

FOURDIGITYEAR

Параметр, определяющий отображаемое число цифр года. Может принимать значения: TRUE (4 цифры), FALSE (2 цифры)

TRUE

YEARBIASED

Параметр, определяющий, прибавлять или нет 1900 к значению года, если предыдущий параметр равен FALSE

TRUE

LEADINGZEROM

Параметр, определяющий, указывать ли лидирующие нули перед значением месяца, если оно является однозначным числом.

FALSE

LEADINGZEROD

Параметр, определяющий, указывать ли лидирующие нули перед значением числа, если оно является однозначным числом.

FALSE

Страница Time позволяет указать параметры отображения времени (см. табл. 3).

Таблица 3. Параметры настройки отображения времени

Параметр

Описание

Значение по умолчанию

TWELVEHOUR

Параметр, определяющий интервал отображения часов: 0-12 (TRUE) или 0-24 (FALSE)

TRUE

AMSTRING

Символьная строка для указания первой половины дня, если TWELVEHOUR=TRUE

AM

PMSTRING

Символьная строка для указания второй половины дня, если TWELVEHOUR=TRUE

PM

SECONDS

Параметр, определяющий, указывать ли секунды в значении времени

TRUE

MILSECONDS

Параметр, определяющий, указывать ли миллисекунды в значении времени .

FALSE

Страница Number позволяет указать параметры отображения числовых данных (табл. 4).

Таблица 4. Параметры настройки отображения чисел

Параметр

Описание

Значение по умолчанию

DECIMALSEPARATOR

Символ, отделяющий дробную часть числа

Значение, содержащееся в настройках панели управления Windows 95/NT

THOUSANDSEPARATOR

Символ, отделяющий друг от друга "тройки" разрядов в многозначных числах

Значение, содержащееся в настройках панели управления Windows 95/NT

DECIMALDIGITS

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

2

LEADINGZERON

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

TRUE

Немного о средствах языковой настройки BDE

Средства языковой настройки BDE представляют собой набор так называемых языковых драйверов, устанавливающих набор символов, используемых в данных, и порядок алфавитной сортировки для используемого языка. Языковые драйверы Borland существуют для большого количества языков, в том числе и для русского.

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

Отметим, что в общем случае языковая настройка баз данных и использующих их приложений включает в себя не только настройку параметра LANGDRIVER на страницах Drivers, Aliases и System. Некоторые СУБД имеют свои средства языковой настройки, причем эти средства могут быть многоуровневыми. Например, в случае использования какой-либо серверной СУБД может потребоваться, помимо настройки BDE, настройка языковых параметров сервера, настройка аналогичных параметров клиентской части или даже выбор соответствующей языковой версии сервера. Подробнее эти проблемы будут рассмотрены чуть позже.

Помимо этого, существует проблема, связанная с различиями DOS- и Windows-кодировок для русского языка. Языковые драйверы BDE существуют для обеих кодировок. Какой из них выбрать, зависит от многих факторов: наличия и объема унаследованных данных, наличия других приложений, использующих эти же данные и др. Например, разумно, используя таблицы формата dBase III совместно с приложениями для DOS, созданными на Clipper, применить DOS-кодировку для этих таблиц.

Особенности настройки BDE для работы с некоторыми источниками данных

dBase

При работе с таблицами dBase настройка соответствующего драйвера сводится к настройке следующих параметров:

Параметр

Описание

Значение по умолчанию

VERSION

Внутренний параметр BDE

1.0

TYPE

Тип сервера (SQL-сервер или файловый сервер)

FILE

LANGDRIVER

Языковый драйвер, определяющий набор символов и порядок алфавитной сортировки

dBASE ENU cp437

LEVEL

Версия формата dBase при создании таблиц

5

MDX BLOCK SIZE

Размер блока, отводимого под индексные файлы *.mdx. Может быть целым числом, кратным 512 K

1024

MEMO FILE BLOCK SIZE

Размер блока, отводимого под файлы memo-полей *.dbt. Может быть целым числом, кратным 512 K

1024

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

С языковой настройкой таблиц dBase обычно не возникает проблем. Для DOS-кодировки обычно используется языковый драйвер dBASE RUS cp866, а для Windows - 'ascii' ANSI.

Следует отметить, что к таблицам dBase можно обращаться, используя ODBC.

Особое внимание следует обратить на то, что расширение *.dbf имеют не только таблицы формата dBase, но и таблицы Clipper, FoxBase, FoxPro. Однако эти СУБД могут иметь другой формат индексных файлов и мемо-полей, которые в явном виде могут не поддерживаться библиотекой BDE (например, индексы *.cdx). В этом случае рекомендуется либо доступ через ODBC (что не всегда эффективно с точки зрения производительности), либо использование библиотек третьих фирм, обеспечивающих интерфейс с такими СУБД (например, Apollo компании SuccessWare).

Paradox

При работе с таблицами Paradox настройка соответствующего драйвера сводится к настройке следующих параметров:

Параметр

Описание

Значение по умолчанию

VERSION

Внутренний параметр BDE

1.0

TYPE

Тип сервера (SQL-сервер или файловый сервер)

FILE

NET DIR

Местоположение файла PDOXUSRS.NET, управляющего совместным использованием таблиц Paradox в сети.

FILE

LANGDRIVER

Языковый драйвер, определяющий набор символов и порядок алфавитной сортировки

'ascii'ANSI

LEVEL

Версия формата Paradox при создании таблиц (3,4,5 или 7)

5

BLOCK SIZE

Размер блока, отводимого для хранения записей таблиц Paradox. Может быть целым числом, кратным 1024 K. Возможные значения зависят от значения параметра LEVEL.

2048

FILL FACTOR

Максимальный процент заполнения блока для индексных файлов.

95

STRICTINTEGRTY

Параметр, определяющий, могут ли таблицы Paradox модифицироваться приложениями, не поддерживающими ссылочную целостность.

TRUE

Как и в случае dBase, русские языковые драйверы для Paradox существуют для обеих кодировок - и DOS, и Windows. Однако указание на используемый язык содержится еще и внутри самих таблиц. Поэтому при создании таблицы Paradox (например, с помощью Database Desktop) следует обязательно указать используемый языковый драйвер при описании свойств таблицы. Как показывает опыт, при неверном определении языка таблицы могут возникнуть проблемы при последующем вводе в нее данных, содержащих русские буквы - некоторые из них после выхода из редактируемого поля могут превратиться в латинские.

ODBC-источники

При работе с ODBC-источниками требуется настройка следующих параметров:

Параметр

Описание

Значение по умолчанию

VERSION

Внутренний параметр BDE

1.0

TYPE

Идентификатор ODBC-источника

FILE

DLL

Имя 16-разрядной динамической библиотеки, содержащей драйвер

IDODBC16.DLL

DLL32

Имя 32-разрядной динамической библиотеки, содержащей драйвер

IDODBC32.DLL

ODBC DRIVER

ODBC-драйвер для соединения с сервером


DRIVER FLAGS

Внутренний параметр BDE


USER NAME

Имя пользователя в диалоге ввода пароля


ODBS DSN

Имя источника данных, описанного в администраторе ODBC


OPEN MODE

Параметр, определяющий, в каком режиме открываются таблицы - READ/WRITE eee READ ONLY

READ/WRITE

LANGDRIVER

Языковый драйвер, определяющий набор символов и порядок алфавитной сортировки

'ascii'ANSI

SCHEMA CASHE SIZE

Число таблиц, чья структура кэшируется. Возможные значения - от 0 до 32

8

SQLQRYMODE

Метод выполнения запросов. Возможные значения: LOCAL - запрос обрабатывается только клиентским приложением, SERVER - запрос выполняется только сервером, NULL (пустая строка) - запрос передается клиенту, если сервер не может его обработать.

NULL

SQLPASSTHRU MODE

Определяет режим совместного использования одного и того же псевдонима направляемыми на сервер и локальными запросами: NOT SHARED - совместное использование запрещено, SHARED AUTOCOMMIT - совместное использованием разрешено с автоматическим завершением транзакций, SHARED NOAUTOCOMMIT - совместное использованием разрешено с завершением транзакций по правилам сервера.

SHARED AUTOCOMMIT

TRACE MODE

Численное значение, определяющее уровень вывода отладочной информации.


SCHEMA CACHE TIME

Время нахождения информации о структуре таблиц в кэше в секундах от 1 до 2147483647. Другие значения: -1 - до закрытия БД, 0 - информация не кэшируется

-1

BATCH COUNT

Число записей, помещаемых в пакет до завершения транзакции

Число записей, умещающихся в 32 К.

MAX ROWS

Максимальное число записей, которые драйвер может доставить на рабочую станцию при выполнении одиночного SQL-запроса

-1 (нет ограничений)

ROWSET SIZE

Число записей, доставляемых в одном блоке данных (поддерживается не всеми ODBC- драйверами).

20

При создании псевдонимов баз данных на страницу Aliases по умолчанию заносятся параметры со страницы Drivers для соответствующего ODBC-драйвера. При необходимости многие из них можно переопределить.

Ряд ODBC-источников требует указания параметра PATH - пути к каталогу, где находится база данных.

Следует обратить внимание на то, что перед описанием ODBC-источника в файле конфигурации BDE обязательно нужно установить соответствующий ODBC-драйвер и описать соответствующий источник данных в панели управления Windows 95/NT, используя соответствующий ODBC-администратор. При этом следует обратить внимание на некоторую терминологическую неувязку. Дело в том, что ODBC-драйвер с точки зрения BDE, создаваемый при нажатии кнопки New ODBC Driver на странице Drivers утилиты конфигурации BDE, на самом деле представляет собой указание не на реальный ODBC-драйвер, установленный в панели управления Windows, а на конкретный источник данных, доступ к которому осуществляется с помощью реального ODBC-драйвера (с точки зрения панели управления). При этом следует еще создать и соответствующий псевдоним базы данных, что окончательно сбивает с толку некоторых начинающих пользователей. Таким образом, последовательность действий при осуществлении доступа к ODBC-источникам следующая:

  • Установить нужный ODBC-драйвер (и, возможно, соответствующий ODBC-администратор для панели управления Windows).

  • Описать с помощью ODBC-администратора необходимый источник данных в панели управления.

  • Запустить утилиту конфигурации BDE и нажать кнопку New ODBC Driver на странице Drivers.

  • Придумать и ввести имя так называемого ODBC-драйвера с точки зрения BDE

  • Выбрать "настоящий" ODBC-драйвер из установленных в операционной системе

  • Выбрать имя источника данных

  • Нажать OK. В списке драйверов появится новый так называемый ODBC-драйвер (с точки зрения BDE).

  • Перейти на страницу Aliases и создать псевдоним, связанный со вновь созданным драйвером с точки зрения BDE.


Рис. 6. Описание нового ODBC-драйвера "с точки зрения BDE".

Отметим, что в версии BDE, поставляемой с Delphi 3.0, вся эта терминологическая путаница ликвидирована, а все описанные в реестре Windows источники данных добавляются в список псевдонимов, и тем самым ликвидируется необходимость выполнения описанной выше инструкции. Остается надеяться, что в следующей версии C++ Builder доступ к ODBC-источникам упростится таким же образом

Для корректного отображения русских букв и установки правильного порядка алфавитной сортировки можно попытаться использовать какой-либо из русскоязычных драйверов dBase или Paradox. Однако следует помнить, что некоторые ODBC-драйверы имеют свои процедуры настройки, которые могут, в частности, включать опцию перекодировки OEM->ANSI (т.е. DOS->Windows). Кроме того, если доступ через ODBC осуществляется к какой-либо серверной СУБД, следует обратить внимание на возможности языковой настройки сервера и клиентской части.

Oracle

Для настройки доступа к серверам Oracle следует настроить примерно тот же набор параметров, что и в случае ODBC-источников. Помимо этого, для драйвера ORACLE существует дополнительный набор параметров:

Параметр

Описание

Значение по умолчанию

VENDOR INIT

Имя библиотеки для соединения клиента с сервером (ORANT.DLL, ORA72.DLL и др.)

ORANT.DLL

SERVER NAME

Имя псевдонима (alias) БД, указанного в файле TNSNAMES.ORA. Если сервер локальный, то SERVER NAME=@2:


NET PROTOCOL

TNS - если используется SQL*Net версии 2.0 или выше, или имя сетевого протокола для доступа к серверу, если используется более ранняя версия SQL*Net.


ENABLE SCHEMA CASHE

Разрешается ли кэширование на рабочей станции структуры таблиц, содержащихся на сервере.

FALSE

SCHEMA CASHE DIR

Каталог для кэширования структуры таблиц.

1.0

ENABLE BCD

Разрешен ли перевод числовых и денежных величин в формат BCD (binary coded decimals) во избежание ошибок округления.

FALSE

ENABLE INTEGERS

Разрешено ли преобразование числовых величин с фиксированной запятой в целый формат.

FALSE

LIST SYNONYMS

Разрешены ли синонимы (альтернативные имена таблиц и представлений) в структурах таблиц: NONE - нет, PRIVATE - разрешены личные синонимы, ALL - разрешены личные и общие синонимы.

NONE

Проблемы установки соединения с Oracle из приложений Borland связаны главным образом с правильной настройкой сетевого программного обеспечения Oracle SQL*Net. Последние версии серверов Oracle (7.2, 7.3) содержат в своем составе SQL*Net версии 2.0 или выше. Для конфигурации SQL*Net 2.0 и выше следует настроить псевдонимы баз данных Oracle с помощью утилиты SQL*Net Easy Configuration, описав сетевое имя или адрес сервера, имя базы данных и тип сетевого протокола. После этого рекомендуется проверить наличие соединения с сервером с помощью утилиты Oracle SQL Plus. Только после проверки соединения можно конфигурировать псевдоним BDE.

При конфигурации псевдонима BDE в качестве сетевого протокола можно указать TNS (Transparent Network Substrate - высокоуровневая надстройка Oracle над сетевыми протоколами). В качестве имени сервера следует указать имя псевдонима базы данных Oracle, указав перед этим именем символ '@' (об этом в документации не сказано). Для локального сервера (или в случае, когда клиентское приложение функционирует на одном компьютере с сервером баз данных, например, Oracle Workgroup Server for Windows NT) в качестве имени сервера можно использовать строку '@2:' .

Для корректного отображения русских букв и установки правильного порядка алфавитной сортировки можно использовать драйверы dBase RUS CP866 или Paradox ANSI Cyrillic в зависимости от того, какая кодировка - DOS или Windows - будет использоваться. Однако корректная работа с русским языком будет обеспечена только в том случае, если удачно подобрано сочетание трех параметров языковой настройки: языковой настройки сервера (она указывается при его установке), языковой настройки клиентской части (значение HKEY_LOCAL_MACHINE//SOFTWARE)//ORACLE//NLS_LANG реестра Windows 95) и собственно языкового драйвера BDE. Подробности языковой настройки клиентской части и сервера можно найти в документации к серверу Oracle.

InterBase

Для настройки доступа к серверам InterBase следует настроить примерно тот же набор параметров, что и в случае ODBC-источников. Помимо этого, для InterBase существует дополнительный набор параметров:

Параметр

Описание

Значение по умолчанию

BLOBS TO CACHE

Определяет, сколько BLOB-полей кэшируется на рабочей станции. Возможные значения: 64 - 65536

64

BLOB SIZE

Определяет размер буфера для BLOB-полей, передаваемых в результате запроса. Возможные значения - 32-100 К. Параметр применим только в случае нередактируемых данных

32 К

Отметим, что при соединении с локальным сервером InterBase следует указывать путь к файлу базы данных.

При возникновении проблем связи C++ Builder с InterBase следует проверить наличие связи с помощью утилиты Interactive SQL. При наличии связи в Interactive SQL следует проверить параметры конфигурации драйвера и псевдонима BDE, а при отсутствии - попробовать найти ошибки в сетевом протоколе, проверив соединение с помощью утилит PING и TELNET.

Более подробно о работе с C++ Builder можно узнать из книги Н.З.Елмановой и С.П.Кошеля "Borland C++ Builder", выходящей в августе в издательстве "Диалог-МИФИ".

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Создание отчетов

Наталия Елманова

Содержание

  • Введение

  • Создание простого отчета

  • Создание отчетов "master-detail"

  • Отображение графических и мемо-полей в отчетах

  • Предварительный просмотр отчетов

Введение

Для генерации отчетов в C++ Builder используется страница QReport на палитре компонентов. Этот набор компонентов позволяет проектировать отчеты на основе таблиц, запросов, списков, текстовых файлов, массивов, используя дизайнер форм C++ Builder.

В комплект поставки C++ Builder входят три шаблона отчетов, содержащиеся на странице Forms репозитария объектов:

Шаблон

Описание

QuickReport Mailing Labels

Шаблон для создания почтовых этикеток

QuickReport List

Шаблон для создания простого табличного отчета

QuickReport Master/detail

Шаблон для создания отчета Master/Detail.

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

Создание простого отчета

Отчеты QuickReport основаны на наборе горизонтальных полос (bands). При построении отчета на форму помещаются несколько компонентов QRBand (наследник TPanel) различных типов.

Для создания простейшего отчета разместим на форме следующие компоненты (рис. 1):

  • TQRBand - компонент, представляющий собой часть отчета - контейнер для размещения данных (например, заголовок отчета, верхний или нижний колонтитул страницы, верхний или нижний колонтитул группы и др.). Компоненты TQRBand печатаются в зависимости от их типа в необходимых местах отчета, независимо от их взаимного расположения на форме. Наиболее часто используемое свойство этого компонента – BandType, тип "полосы" (колонтитул страницы или группы, "полоса" данных и др.). Возможные значения: rbTitle – заголовок отчета, rbPageHeader – верхний колонтитул страницы, rbColumnHeader – верхний колонтитул колонки в многоколоночном отчете, rbDetail – полоса с табличными данными (повторяется столько раз, сколько строк имеется в наборе данных, авляющемся основой отчета), rbPageFooter – нижний колонтитул страницы, rbOverlay – фон страницы, печатается в левом верхнем углу каждой страницы, rbGroupHeader – заголовок группы, rbSubDetail – "полоса" табличных данных для Detail-таблицы, rbGroupFooter – нижний колонтитул группы, rbSummary – печатается в конце отчета). Свойству BandType созданного нами компонента присвоим значение rbTitle

  • TQuickReport (этот компонент отвечает за превращение формы в отчет).

  • TQRLabel, помещенный на QRBand1 (этот компонент предназначен для вывода статического текста, и его свойству Caption можно присвоить значение, равное тексту заголовка будущего отчета).



Рис. 1. Создание заголовка отчета

Если нажать правую клавишу мыши над компонентом QuickReport1 и выбрать из контекстного меню опцию Preview Report, появится окно просмотра, в котором будет отображена страница отчета с созданным заголовком.

Для модификации отчета следует изменить свойство BandType компонента QRBand1 на rbDetail и добавить на форму компонент TTable. Далее нужно установить его свойство DataBase равным имени псевдонима, например, BCDEMOS, свойство TableName равным имени таблицы, например, CUSTOMER.DB, а затем свойство Active равным true. После этого нужно добавить на форму компонент TDataSource и установить его свойство DataSet равным имени добавленного ранее компонента Table1, а затем установить свойство DataSource компонента QuickReport равным имени созданного компонента DataSource1. После этого можно добавить компонент TQRDBText на QRBand1(этот компонент предназначен для вывода содержимого полей таблицы или запроса, служащего источником данных проектируемого отчета), установить свойство DataSource равным имени созданного ранее компонента DataSource1 и выбрать нужное поле в качестве значения свойства DataField. Если есть необходимость, можно добавить другие компоненты TQRDBText и выбрать другие поля таблицы для отображения в отчете (рис. 2).


Рис. 2. Модификация табличного отчета

Если теперь из контекстного меню компонента QuickReport выбрать опцию Preview Report, можно увидеть модифицированный табличный отчет.

Теперь попробуем создать отчет с заголовком отчета и колонтитулами. Для этого нужно использовать при создании отчета несколько различных компонентов TQRBand.

Для создания отчета с заголовком и колонтитулами следует cоздать новую форму, разместить четыре компонента TQRBand на форме (они получат по умолчанию имена QRBand2,...., QRBand5) и установить их свойства BandType равными соответственно rbTitle, rbColumnHeading, rbDetail и rbPageFooter. Далее следует добавить на форму компонент TTable и установить его свойство DatabaseName равным BCDEMOS, свойство TableName равным Customer, а затем свойство Active равным true. Затем нужно добавить на форму компонент TDataSource и установить в его свойстве DataSet имя добавленного ранее компонента Table1 и установить свойство DataSource компонента QuickReport равным имени созданного компонента DataSource1. Затем следует добавить несколько компонентов TQRLabel в качестве заголовка отчета и столбцов поверх соответствующих компонентов TQRBand, присвоив необходимые значения свойству Caption каждого из них.

Затем следует разместить три компонента QRDBText на компонент QRBand со свойством BandType, равным DetailBand и установить их свойства DataSource равными DataSource1, а свойства DataField равными Company, Phone и Fax. Наконец, для отображения номера страницы нужно поместить компонент TQRSysData (этот компонент предназначен для вывода сведений, не зависящих от содержимого данных, таких как номер страницы, дата, время и др.) на компонент TQRBand со свойством BandType, равным rbPageFooter и установить его свойство Data равным qrcPageNumber, а свойство Text равным “Стр. “

После этого форма будет выглядеть, как на рис. 3.

Можно снова выбрать опцию Preview Report и просмотреть содержание нового отчета.


Рис.3. Отчет с заголовком и колонтитулами

Создание отчетов "master-detail"

Преобразуем созданный отчет в отчет "master-detail". Для этого следует добавить компонент TTable, установить его свойство DatabaseName равным BCDEMOS, свойство TableName равным ORDERS.DB, а затем установить свойство Active равным true. После этого установим свойство MasterSource равным DataSource1. Затем выберем свойство MasterFields, вызвав диалоговую панель для установки связи master/detail (рис. 4 ) и из списка доступных индексов выберем CustNo. Затем выделим имя поля CustNo в обоих списках полей и нажмем кнопку Add, а кнопку OK.


Рис. 4. Установка связи master/detail

Добавим на форму компонент TDataSource, установив его свойство DataSet равным Table2 . Затем добавим к форме новый компонент TQRBand (c именем QRBand6). После этого добавим компонент TQRDetailLink, предназначенный для установки связей между источниками данных в отчетах, и установим его свойство DataSource равным DataSource2. Затем установим его свойство Master равным QuickReport, а свойство DetailBand равным QRBand6. Свойство BandType компонента QRBand6 автоматически примет значение rbSubDetail.

Наконец, поместим два компонента TQRDBText на QRBand6, установим их свойства DataSource равными DataSource2, а свойства DataField равными OrderNo и AmountPaid. Слева от них поместим два компонента TQRLabel с названиями этих полей (рис. 5).


Рис. 5. Форма отчета "master-detail".

  1. Выберем опцию Preview Report из контекстного меню компонента QuickReport для предварительного просмотра отчета (рис.6).


Рис. 6. Отчет "master-detail".

Отметим, что если компонент QuickReport не связан с компонентом DataSource, то при печати отчета выводится только одна запись из набора данных, что легко позволяет печатать текущую запись.

Отображение графических и мемо-полей в отчетах

QuickReport позволяет создавать отчеты с использованием любых типов данных. Если вместо определения DataSource создать обработчик события OnNeedData, можно с помощью QuickReport напечатать любые данные, меняя свойства компонентов TQRLabel, что во многих случаях используется для печати произвольной информации (иногда не имеющей отношения к базам данных).

QuickReport не имеет собственного компонента для отображения графических полей. Вместо этого можно использовать стандартные компоненты Timage или TDBImage (рис. 7).


Рис. 7. Использование TDBImage для отображения графических полей

Следует отметить, что графические поля баз данных может печатать далеко не всякий профессиональный генератор отчетов. Например, ReportSmith, входивший в комплект поставки ряда продуктов Borland, может печатать графические изображения, не имеющие непосредственного отношения к данным (например, взятые из файлов формата *.bmp), но отнюдь не графические поля таблиц.

Для отображения мемо-полей можно использовать компонент TQRDBText. Если содержимое мемо-поля, отображаемого с помощью этого компонента, не умещается в одну строку, высота этого компонента (и высота содержащего его компонента TQRBand) в режиме предварительного просмотра и при печати отчета увеличивается таким образом, чтобы внутри компонента TQRDBText уместилось все содержимое memo-поля. Чтобы избежать наложения получившегося текста на другие элементы отчета при его печати, можно просто размещать компоненты TQRDBText, отображающие memo-поля, в нижней части TQRBand (рис 7).


Рис. 7. В левой нижней части данного отчета компонент TQRDBText отображает memo-поле


Рис. 8. А вот так выглядят memo-поля в отчете

Если таких memo-полей несколько и они должны быть размещены друг под другом, можно использовать несколько компонентов TQRBand одного типа для одной записи. В этом случае печататься они будут в порядке их создания.

Предварительный просмотр отчетов

В некоторых случаях требуется предварительный просмотр отчетов на этапе выполнения. Для этой цели используется метод Preview() компонента TQuickReport. При его выполнении на экране появится стандартная форма просмотра, изображенная на рис. 8.

Если внешний вид стандартной формы просмотра по какой-либо причине вас не устраивает, можно создать свою форму предварительного просмотра с помощью компонента QRPreview. Этот компонент обладает свойствами PageNumber и Zoom, которые можно использовать для просмотра произвольной страницы отчета в произвольном масштабе.

Для создания собственного окна предварительного просмотра следует на вновь созданной форме разместить компонент QRPreview и набор элементов управления (например, кнопок) для перемещения между страницами, изменения масштаба, печати и др. Далее следует написать код, аналогичный приведенному ниже примеру:

void __fastcall TForm1::ShowPreview()
{
Form2->ShowModal();
}
void __fastcall TForm1::Button1Click(TObject *Sender)
{
QRPrinter->OnPreview=ShowPreview;
Form4->QuickReport1->Preview();
Form2->ShowModal();
}

Кроме того, нужно внести прототип функции ShowPreview() в соответствующий h-файл:

__published: // IDE-managed Components
TButton *Button1;
void __fastcall Button1Click(TObject *Sender);
void __fastcall ShowPreview(void);

Приведенный пример кода показывает, как связать созданную форму с компонентом QuickReport. Эта связь достигается написанием обработчика события QRPrinter->OnPreview. Это событие не имеет прямого отношения к компоненту QuickReport, иначе нужно было бы связывать все созданные отчеты с окном просмотра. Использование события объекта QRPrinter обычно означает написание общего для всех отчетов обработчика события, после чего окно просмотра можно использовать для всех имеющихся в приложении отчетов.

Более подробно о компонентах, используемых для создания отчетов, можно прочесть в книге "Введение в Borland C++ Builder" Н.Елмановой и С.Кошеля, вышедшей в июле этого года в издательстве "Диалог-МИФИ".


























































++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++


Поставка приложений, созданных с помощью С++ Builder

Наталия Елманова

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

Содержание

  • Поставка исполняемых файлов

  • Установка и настройка Borland Database Engine

  • Установка дополнительных компонентов приложения

  • Способы создания дистрибутивов

  • Создание дистрибутивов с помощью InstallShield Express

Поставка исполняемых файлов

При окончательной сборке исполняемого файла (то есть непосредственно перед созданием дистрибутива) следует убрать из исполняемого файла отладочную информацию. Для этого следует из менеджера проектов вызвать диалоговую панель Project Options и нажать кнопку Release. Рис. 1. Установка параметров компилятора C++ при окончательной сборке приложения.

Если в проекте используются модули и формы Delphi, следует отключить все опции в секции Debugging и включить опцию Optimization в секции Code Generation на странице Pascal.

В той же диалоговой панели следует выбрать пиктограмму приложения (страница Application). Eе можно создать с помощью входящего в комплект поставки С++ Builder графического редактора, который можно запустить, выбрав пункт меню Tools/image Editor. Помимо этого, следует указать название приложения (то есть строку, которая будет отображаться в панели задач Windows 95) и имя файла справки, в котором содержатся экраны контекстно-зависимой помощи. Более подробно о создании контекстно-зависимой помощи для приложений С++ Builder можно узнать в книге "Введение в Borland C++ Builder" (Н.Елманова, С.Кошель. - М.: Диалог-МИФИ, 1997). Рис. 2. Установка названия, пиктограммы и имени файла справки.

Если ссылка на справочный файл присутствует в опциях проекта, можно связать экраны помощи с интерфейсными элементами приложения. Для этой цели следует установить значения свойства HelpContext интерфейсных элементов приложения равным номерам разделов соответствующих экранов помощи из секции [MAP] файла проекта справки. В этом случае после компиляции приложения нажатие на клавишу F1 будет выводить на экран окно справочной системы с разделом справки, описывающим интерфейсный элемент, имеющий фокус ввода.

Установка и настройка Borland Database Engine

Если приложение не использует базы данных, в большинстве случаев будет достаточно просто скопировать на компьютер пользователя исполняемый файл и другие входящие в комплект поставки файлы (например, файл справки, файл оглавления справки и др.).

Если приложение использует базы данных, следует, помимо приложения, установить на компьютер пользователя библиотеку Borland Database Engine. Установка этой библиотеки заключается в копировании файлов этой библиотеки на компьютер пользователя, внесении сведений о ней в реестр (раздел HKEY_LOCAL_MACHINE//SOFTWARE//Borland//Database Engine), установке пиктограммы для утилиты конфигурации BDE, а также настройке псевдонимов, необходимых для корректной работы данного приложения.

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

Можно посмотреть на эту проблему с другой стороны. Как избежать потери работоспособности вашего приложения, если другой программист установит свой файл конфигурации BDE поверх установленного вами? Возможное решение этой проблемы - создавать псевдонимы динамически во время работы приложения или анализировать их существование при запуске и создавать их, если по каким-то причинам они исчезли. Многие разработчики хранят информацию о них в локальных ini-файлах вне IDAPI32.CFG.

Вторая проблема может быть связана с несовпадением версий BDE. Если с момента выхода используемой вами версии BDE прошло какое-то время (а на данный момент после C++ Builder появились такие продукты, как Delphi 3.0 и IntraBuilder 1.5, содержащие более новую версию BDE, чем С++ Builder), есть риск заменить старой версией BDE более новую, если на компьютере пользователя установлены эти средства разработки или созданные с их помощью приложения, что может нарушить их работоспособность.

Чтобы избежать подобных неприятностей, можно воспользоваться одной недокументированной особенностью BDE. Дело в том, что время создания файлов этой библиотеки совпадает с номером версии BDE, чем и можно воспользоваться. Путь к файлам BDE следует искать в реестре Windows (ключ HKEY_LOCAL_MACHINE\SOFTWARE\Borland\Database Engine, параметры CONFIGFILE01 и DLLPATH). Рис. 3. Сведения о BDE в реестре Windows 95

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

Отметим, что следует также установить на компьютер пользователя необходимые драйверы SQL Links для доступа к серверным СУБД, если они используются, а также клиентское программное обеспечение для работы с соответствующей серверной СУБД (например, SQL*Net для Oracle). Кроме того, пользователь должен обладать необходимыми привилегиями для доступа к используемым вашим приложением объектам базы данных - таблицам, хранимым процедурам и др. Если вы готовите и серверную часть приложения, следует предоставить администратору базы данных так называемый DDL-сценарий серверной части (DDL - Data Definition Language), представляющий собой сценарий создания объектов базы данных, написанный на SQL либо на его процедурном расширении, характерном для данного сервера баз данных. Подобный сценарий может быть создан вручную либо с помощью какого-либо CASE-средства типа ERwin компании Logic Works (CASE, что расшифровывается как Computer-Aided Software/System Engineering, представляет собой технологию проектирования БД, основанную на графическом описании сущностей, атрибутов и связей между ними).

Если ваше приложение использует ODBC, следует установить соответствующий ODBC-драйвер и, возможно, 32-разрядный ODBC-администратор - он в общем случае не обязан присутствовать на компьютере пользователя.

Установка дополнительных компонентов приложения

Если ваше приложение использует ActiveX-компоненты, следует установить в каталог Windows\System соответствующий файл *.OCX и внести в реестр соответствующие ветви (HKEY_CLASS_ROOT\CLSID\....) для регистрации соответствующих OLE-серверов.

Если ваше приложение использует какие-либо продукты третьих фирм (например, Run-time-версии генераторов отчетов сторонних производителей, например, Crystal Reports), следует установить их на компьютер пользователя в соответствии с инструкциями по поставке, предоставленными компанией-производителем.

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

Самый простой способ - не использовать экзотических шрифтов. Шрифты типа Arial, Courier и Times New Roman, как правило, есть на всех компьютерах. Если же такой уверенности нет, можно либо предложить пользователю выбирать шрифты для приложения при его запуске и сохранять настройки в файлах (это неудобно, так как при этом надписи могут не уместиться на кнопках, метки могут "наехать" друг на друга и т.д.), либо инсталлировать нужные шрифты вместе с приложением. В случае Windows 95 достаточно скопировать их в каталог Fonts. Можно также присвоить "своим" шрифтам уникальные нестандартные имена, чтобы случайно не заменить ими шрифты, используемые другими приложениями (заменив в англоязычной версии Windows шрифт Arial его русскоязычной версией, вы в некоторых случаях можете лишить вашего пользователя возможности писать в текстовых процессорах по-французски или по-немецки этим шрифтом).

Способы создания дистрибутивов

Прежде чем описать процесс создания дистрибутива, рассмотрим, что именно делает инсталляционное приложение.

Во-первых, оно, как следует из вышеизложенного, копирует файлы (*.exe, *.ocx, *.dll, *.hlp, шрифты, данные и др.) в соответствующие каталоги.

Во-вторых, оно может модифицировать реестр.

В- третьих, оно может модифицировать переменную окружения PATH.

В-четвертых, оно создает программную группу и пиктограммы, а также модифицирует меню Windows-95 или Windows NT.

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

В-шестых, оно может при необходимости перезапустить Windows.

Как создать инсталляционное приложение? Существует несколько вариантов решения этой проблемы. Во-первых, его можно написать на C++ Builder или Delphi, используя функции Windows API для модификации реестра согласно алгоритму, изложенному выше. Подробности создания таких инсталляционных программ с помощью Delphi 2.0 описаны, например, в статье Алексея Федорова "Delphi: сделай инсталлятор сам" (Компьютер-Пресс, 1996, N 9, стр.46-50), и приведенные в этой работе примеры легко переносятся с Object Pascal на C++. Во-вторых, такое приложение можно создать с использованием генераторов дистрибутивов (InstallShield, Wise и др.). Отметим, что использование этих средств обычно подразумевает написание специализированного скрипта на языке, напоминающем С (в случае InstalShield) или Basic (в случае Wise).

Однако самый простой способ создать инсталляционное приложение - использовать входящий в комплект поставки версий Borland C++ Builder версий Professional и Client/Server Suite упрощенный генератор дистрибутивов Install Shield Express, позволяющий предоставить пользователю возможность выбора варианта инсталляции, добавить деинсталлятор (точнее, файл с расширением *.isu, используемый утилитой установки и удаления программ Windows 95), установить BDE, добавить псевдонимы баз данных, редактировать диалоги инсталляционного приложения, создавать программные группы, создавать дистрибутивные дискеты.

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

Тем не менее, если перечисленные недостатки не очень важны или могут быть устранены в конкретном случае (например, путем выбора варианта инсталляции), использование данного средства может сэкономить довольно много времени при создании дистрибутива приложения.

Создание дистрибутивов с помощью InstallShield Express

При запуске Install Shield Express появляется окно с радиогруппой, предлагающее открыть существующий проект или создать новый.

При создании нового проекта следует ввести имя проекта и указать каталог, в котором расположены файлы приложения (рис. 4). Рис. 4. Создание нового дистрибутива

Флажок "Include custom setup type" следует выбрать, если вы планируете предоставить пользователю возможность выбора варианта инсталляции Custom Setup для самостоятельного выбора варианта инсталляции. После этого появится главный экран InstallShield, в котором перечислена последовательность шагов, которые следует выполнить для создания дистрибутива (рис. 5). Рис. 5. Главный экран InstallShield Express

В разделе Set the Visual Design следует заполнить поля со сведениями о приложении: название приложения, как оно будет выглядеть в программной группе, имя исполняемого файла, каталог, в который следует установить приложение (рис. 6)

Рис. 6. Установка параметров приложения

Отметим, что Install Shield содержит несколько переменных, идентифицирующих диски и каталоги компьютера пользователя, что позволяет не знать реальную систему каталогов и дисков этого компьютера:

  • - каталог для установки, указанный пользователем,

  • - каталог, в котором содержится Windows

  • - каталог Windows\System

  • - диск, на котором содержится Windows

  • - диск, на котором содержится каталог Windows\System

  • - каталог Program Files.

Щелкнув на закладке Main Window, можно установить заголовок инсталляционного приложения, цвет фона и логотип (рис.7). Рис. 7. Установка внешнего вида экрана инсталлятора

Щелкнув на закладке Features, можно обнаружить одну-единственную опцию - Automatic Uninstaller. Ее рекомендуется оставить выбранной.

Следующий раздел - Specify InstallShield Options for Borland C++ - предназначен для выбора компонентов, часто поставляемых с приложениями: BDE, SQL Links и др. Выбрав нужный компонент (в нашем случае BDE) и нажав кнопку Settings, получим последовательность из четырех диалоговых окон для выбора частей BDE, поставляемых с данным приложением (рис. 8 ), и создания псевдонимов. Рис. 8. Определение устанавливаемых частей BDE

При установке параметров псевдонимов можно выбрать тип псевдонима и местоположение данных. Остальные параметры псевдонима (в том числе и языковые драйверы) можно указать в текстовом редакторе в нижней части окна (рис. 9):

Рис. 9. Установка параметров псевдонимов BDE

Щелкнув по закладке Advanced Options, можно ознакомиться со списком файлов дополнительных компонентов (в нашем случае BDE) и сведениями о них.

Следующий раздел - Specify Components and Files - предназначен для определения групп файлов, компонентов приложения и типов установки. Щелкнув на закладке Groups, можно создать группы файлов для создания из них компонентов дистрибутива. Можно также использовать Explorer и переносить из него нужные файлы методом drag-and-drop (для этого нужно нажать кнопку Launch Explorer). Не рекомендуется оставлять группы пустыми.

Рис. 10. Создание групп файлов

Щелкнув на закладке Components, можно определить компоненты дистрибутива (их сможет выбирать пользователь в случае выбора варианта инсталляции Custom, поэтому можно дать им русскоязычные названия) и указать, из каких групп файлов они состоят. Не следует оставлять компоненты, не содержащие групп. Рис. 11. Создание компонентов дистрибутива

Следующая закладка - Setup Types - предназначена для определения вариантов установки. Если щелкнуть на ней, может оказаться, что вариант инсталляции его один - Typical (например, вы забыли отметить флажок "Include custom setup type"). В этом случае следует выбрать раздел Select User Interface Components и, щелкнув на закладке Components, в списке Dialog Boxes отметить опции Setup Type и Custom Setup. После этого можно вернуться к закладке Setup Types и определить варианты инсталляции. Как правило, варианты Custom и Typical содержат все возможные компоненты, а вариант Compact - минимальный набор компонентов, пригодный для нормальной работы приложения. Рис. 12. Определение состава вариантов инсталляции

В разделе Select User Interface Components можно выбрать диалоги, в которых пользователь вводит необходимую информацию во время инсталляции (например, сведения о себе и компании, серийный номер продукта), знакомится с лицензионным соглашением и файлам readme, указывает каталог для инсталляции, выбирает тип установки и т.д. Возможен также предварительный просмотр диалогов при нажатии кнопки Preview.

Следующий раздел - Make Registry Changes - позволяет создавать на компьютере пользователя новые ключи реестра (закладка Keys) и значения ключей (Values). Это может оказаться полезным, если вы используете в вашем приложении компоненты ActiveX или создаете OLE-сервер. Ключи и их значения можно копировать из редактора реестра, если он поддерживает такую опреацию.

Рис.13. Определение ключей и значений реестра компьютера пользователя.

Следующий раздел - Specify Folders and Icons - позволяет определить состав будущей программной группы, а также определить параметры командной строки (закладка Advanced). Рис. 14. Определение состава программной группы.

Наконец, последний раздел - Run Disk Builder. После сохранения инсталляционного скрипта (с помощью нажатия на кнопку с изображением дискеты на панели инструментов главного окна InstallShield) и выбора типа носителей происходит создание на жестком диске образов дистрибутивных дискет. Выбрав затем раздел Create Distribution Media, можно записать на дискеты созданный дистрибутив. Рис. 15. Создание образов дискет.

Опцию Test Run можно использовать для проверки работы инсталляционного приложения. Однако не рекомендуется делать это на компьютере, где производится разработка приложений. Лучше провести тестовые испытания на компьютере, похожем на компьютеры ваших пользователей. Кроме того, рекомендуется создать на этом компьютере копию Windows, чтобы в случае некорректной работы инсталлятора можно было вернуть программное обеспечение в исходное состояние.

Запуск инсталляционной программы приводит к последовательному появлению выбранных в разделе Select User Interface Components диалогов, подобных изображенному на рис. 16. Рис. 16. Так выглядит один из диалогов программы установки

Результатом работы инсталляционного приложения является установка приложения и необходимых для его работы файлов на компьютер пользователя, создание программной группы, внесение необходимых ключей в реестр (рис.17). Рис. 17. Результат работы инсталляционного приложения.

Если при создании дистрибутива вы выбрали опцию Automatic Uninstaller, то в случае возникновения необходимости деинсталляции установленного приложения следует использовать утилиту "Установка и удаление программ" в панели управления Windows.

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

В заключение отметим, что поставка приложений, созданных с помощью Delphi 2.0 и Delphi 3.0, осуществляется практически точно так же, как и поставка приложений, созданных с помощью C++ Builder.

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++


Перенос приложений C++Builder в архитектуру клиент/сервер

Наталия Елманова

Содержание

  • Введение

  • Немного истории

  • Особенности архитектуры клиент/сервер

  • Серверные СУБД и унаследованные данные

  • Перенос унаследованных данных с помощью Data Migration Wizard

  • Перенос унаследованных данных с использованием CASE-средств

  • Некоторые выводы

Введение

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

Немного истории

Давайте отвлечемся от современных технических средств и программных продуктов, используемых при построении информационных систем, и вспомним, что происходило два десятилетия назад. В те времена при построении информационных систем самой популярной была модель “хост-компьютер + терминалы”, реализованная на базе мэйнфреймов (например, IBM-360/370, или их отечественных аналогов - компьютеров серии ЕС ЭВМ), либо на базе так называемых мини-ЭВМ (например, PDP-11, также имевших отечественный аналог – СМ-4). Характерной особенностью такой системы была полная “неинтеллектуальность” терминалов, используемых в качестве рабочих мест – их работой управлял все тот же хост-компьютер (рис.1)


Рис.1. Этап 1: модель "хост-компьютер + терминалы"

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

В чем были недостатки подобной архитектуры вычислений? Главным образом в полной зависимости пользователя от администратора хост-компьютера. Фактически пользователь (а нередко и программист) не имел возможности настроить рабочую среду под свои потребности – используемое программное обеспечение, в том числе и текстовые редакторы, компиляторы, СУБД, целиком и полностью было коллективным.

Не будет, наверное, большим преувеличением сказать, что в значительной степени именно этот недостаток подобных систем привел к бурному (и не прекратившемуся до сих пор) развитию индустрии персональных компьютеров. Наряду с дешевизной и простотой эксплуатации достаточно привлекательной особенностью настольных информационных систем стала так называемая персонализация рабочей среды, когда пользователь мог выбрать для себя инструменты для работы (текстовый редактор, СУБД, электронную таблицу и др.), наиболее соответствующие его потребностям. Естественно, и инструментов этих на рынке программных продуктов появилось довольно много. Именно в этот период появились электронные таблицы и настольные СУБД (dBase, FoxBase, Сlipper, Paradox и др.), нередко совмещающие в себе собственно СУБД и средства разработки приложений, использующих базы данных.


Рис.2. Этап 2: автономная персональная обработка данных

Следующим этапом развития архитектуры информационных систем было появление сетевых версий вышеупомянутых СУБД, позволяющих осуществлять многопользовательскую работу с общими данными в локальной сети. Этот подход сочетал в себе как удобства персонализации пользовательской среды и простоты эксплуатации, так и преимущества, связанные со вновь открывшимися возможностями совместного использования периферии (главным образом сетевых принтеров и сетевых дисков, в том числе хранящих коллективные данные). Отметим, что большинство информационных систем, реально эксплуатируемых сегодня в нашей стране, имеют именно такую архитектуру (в том числе некоторые информационные системы, реализованные на Delphi и C++Builder), и в случае не очень большого количества пользователей системы, не слишком большого объема данных и количества таблиц, невысоких требований к защите данных этот подход себя, безусловно, оправдывает.


Рис.3. Этап 3: коллективная обработка данных с использованием сетевых версий настольных СУБД и файлового сервера

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

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

Возросший сетевой трафик – не единственная неприятность, подстерегающая администратора и разработчика подобной информационной системы. Весьма частым явлением в этом случае является нарушение ссылочной целостности данных. Возьмем уже ставший классическим пример, приводимый во всех учебниках по базам данных. Имеются две таблицы формата dBase: список заказчиков какой-либо компании, и список их заказов, связанные по какому-либо полю, например, CUST_ID (рис.4). Вполне разумными требованиями, предъявляемыми к такой БД (иногда называемыми бизнес-правилами), являются уникальность значений этого поля в списке заказчиков (иначе как узнать, чьи заказы с этим CUST_ID находятся в таблице заказов?), и отсутствие в списке заказов записей со значениями CUST_ID, отсутствующими в таблице заказчиков (то есть “ничьих” заказов). В случае dBase выполнение таких требований реализуется на уровне логики приложения. При этом практически всегда имеется возможность произвольного редактирования таблиц иными средствами (от dBase III до обычных текстовых редакторов), что может привести к нарушению этих требований. Обычно для предотвращения подобных прецедентов используются различные организационно-технические меры, например, запрещение средствами сетевой ОС доступа к файлам с таблицами иначе как из конкретного приложения. При этом полной гарантии сохранения ссылочной целостности все равно нет, так как остается вероятность так называемых незавершенных транзакций (то есть попытки согласованного изменения данных в нескольких таблицах – например, удаления заказчика вместе со всеми его заказами, во время которого произошел сбой питания, в результате чего удалилась только часть данных). Отметим также, что если информационная система содержит несколько приложений, использующих общие данные, каждое из них должно содержать код, предотвращающий некорректное с точки зрения ссылочной целостности изменение данных.



Рис.4.Пример связи "один-ко-многим"

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

Особенности архитектуры клиент/сервер

Что же представляет собой архитектура клиент/сервер? В определенной степени ее можно назвать возвратом к модели “хост-компьютер+терминалы”, так как ядром такой системы является сервер баз данных, представляющий собой приложение, осуществляющее комплекс действий по управлению данными – выполнение запросов, хранение и резервное копирование данных, отслеживание ссылочной целостности, проверку прав и привилегий пользователей, ведение журнала транзакций. При этом в качестве рабочего места может быть использован обычный персональный компьютер, что позволяет не отказываться от привычной рабочей среды.


Рис.5. Этап 4: обработка данных в архитектуре клиент/сервер

В чем преимущества клиент-серверных информационных систем по сравнению с их аналогами, созданными на основе сетевых версий настольных СУБД?

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

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

Кроме того, для описания серверных бизнес-правил в наиболее типичных ситуациях (как в примере с заказчиками и заказами) существуют весьма удобные инструменты - так называемые CASE-средства (CASE означает Computer-Aided System Engineering), позволяющие описать подобные правила, и создавать реализующие их объекты базы данных (индексы, триггеры), буквально рисуя мышью связи между таблицами без какого бы то ни было программирования. В этом случае клиентское приложение будет избавлено от значительной части кода, связанного с реализацией бизнес-правил непосредственно в приложении. Отметим также, что часть кода, связанного с обработкой данных, также может быть реализована в виде хранимых процедур сервера, что позволяет еще более "облегчить" клиентское приложение, а это означает, что требования к рабочим станциям могут быть не столь высоки. Это в конечном итоге удешевляет стоимость информационной системы даже при использовании дорогостоящей серверной СУБД и мощного сервера баз данных.

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

Итак, клиент-серверная информационная система состоит в простейшем случае из трех основных компонентов:

  • сервер баз данных, управляющий хранением данных, доступом и защитой, резервным копированием, отслеживающий целостность данных в соответствии с бизнес-правилами и, самое главное, выполняющий запросы клиента;

  • клиент, предоставляющий интерфейс пользователя, выполняющий логику приложения, проверяющий допустимость данных, посылающий запросы к серверу и получающий ответы от него;

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

Есть и более сложные реализации архитектуры клиент/сервер, например, трехуровневые информационные системы с использованием серверов приложений, но это уже тема отдельного разговора.

Серверные СУБД и унаследованные данные

Одной из наиболее распространенных проблем, связанных с модернизацией эксплуатируемых информационных систем, является использование в них данных, унаследованных от прежних версий и содержащихся, как правило, в форматах настольных СУБД. В частности, вопросы модернизации устаревших систем на основе xBase и переноса их на платформу Oracle, а также этапы модернизации с организационной точки зрения были подробно проанализированы Алексеем Ярцевым в статье "Миграция из xBase в Oracle'' ("Компьютер -Пресс", 1997, N 8, стр.137-140).

В данной работе хотелось бы рассмотреть некоторые технические аспекты проблемы использования унаследованных данных применительно к С++Builder.

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

Перенос унаследованных данных с помощью Data Migration Wizard

Способов переноса данных может быть несколько. Первый, самый примитивный, и, к сожалению, весьма распространенный, представляет собой перенос структур данных и самих данных "как есть" с одной платформы на другую с заменой типов данных настольной СУБД на эквивалентные им типы данных сервера. Этой цели служит утилита Data Migration Wizard, входящая в комплект поставки C++Builder. Рассмотрим ее работу на простом примере из двух связанных таблиц. Для этой цели вполне подойдут таблицы CLIENTS.DBF (список клиентов) и HOLDINGS.DBF (список зданий), связанные отношением "один ко многим". Такой пример выбран потому, что таблица CLIENTS содержит графические и мемо-поля, при переносе которых с платформы на платформу нередко возникают проблемы (в отличие от символьных и числовых полей, для которых обычно можно подобрать эквивалентный тип данных). В качестве серверной СУБД используем 90-дневную trial-версию Personal Oracle 7.2 для Windows 95 или Oracle Workgroup Server 7.2.для Windows NT (в принципе подобный пример можно выполнить и с помощью входящего в комплект поставки С++Builder локального сервера InterBase). Перед тем как выполнить данный пример, запустим сервер и с помощью входящей в комплект поставки утилиты администрирования сервера (в нашем случае Personal Oracle Navigator) опишем пользователя USER1, от имени которого будут создаваться таблицы, проверив заодно наличие соединения с базой данных.


Рис 6. Создание пользователя с помощью Personal Oracle Navigator

Далее опишем параметры псевдонима используемой базы данных:


Рис.7. Создание псевдонима для доступа к данным Oracle

Отметим, что 2: - имя локального сервера Oracle (при работе с Oracle Workgroup Server for Windows NT, расположенном на том же компьютере, что и С++Builder, можно использовать такое же имя сервера). В случае удаленного сервера следует описать местоположение и доступ к базе данных (имя БД, сетевой протокол, IP-адрес или сетевое имя компьютера) с помощью утилиты SQL*Net Easy Configuration, входящей в комплект поставки серверов Oracle последних версий.

После описания доступа к БД рекомендуется проверить правильность настроек BDE. Это можно сделать, запустив SQL Explorer и попытавшись открыть какую-либо из таблиц Oracle (любая современная серверная СУБД, как правило, содержит какие-либо таблицы в качестве примера). Если список таблиц получить не удается, следует проверить, есть ли в переменной окружения PATH каталог типа С:\ORAWIN95\BIN, и есть ли в каталоге WINDOWS\SYSTEM файлы типа ORA72.DLL или ORANT71.DLL.

После проверки настроек BDE можно приступить непосредственно к переносу таблиц. Запустим Data Migration Wizard:


Рис.8. Выбор исходной БД в Data Migration Wizard

Далее выберем псевдоним БД, в которую мы осуществляем экспорт данных, и затем выберем имена экспортируемых таблиц:


Рис.9. Выбор таблиц для переноса данных с помощью Data Migration Wizard

После этого получим экран, содержащий список таблиц и индексов, подлежащих переносу.


Рис.10. Список таблиц и индексов, подлежащих переносу.

Если нажать кнопку Modify Mapping Information For Selected Item, получим сведения о том, в какие типы данных будут преобразованы поля исходных таблиц. При необходимости в эти сведения можно внести правки.


Рис.11. Внесение правок в правила преобразования полей

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

Достоинством этого метода переноса данных является его простота. Но при его применении далеко не все преимущества архитектуры клиент/сервер оказываются использованными. Скорость выполнения запросов к данным, хранящимся теперь в серверной базе данных, действительно может возрасти - их будет выполнять сервер. Однако, перенося данные таким способом, мы создали на сервере только то, что было в исходной базе данных - таблицы и индексы. Новые объекты серверной базы данных, реализующие бизнес-правила, такие, как триггеры и хранимые процедуры, при этом созданы не будут - их придется создавать вручную, занимаясь кодированием на процедурном расширении SQL, характерном для данного сервера, либо, как и в случае настольных СУБД, описывать их внутри клиентского приложения, рискуя нарушить ссылочную целостность данных. Если мы попытаемся создать приложение, работающее с только что созданными нами таблицами, то сумеем в этом убедиться.

Для создания такого приложения воспользуемся инструментом под названием Database Form Wizard. Запустим C++Builder, создадим новый проект, удалим из него пустую форму и выберем со страницы Forms репозитария объект Database Form:


Рис.12. Выбор Database Form из репозитария С++Builder

Далее выберем создание формы master/detail c использованием объектов TTable:


Рис.13. Выбор типа будущей главной формы приложения

После выбора псевдонима базы данных Oracle из списка псевдонимов определим master-таблицу. В нашем случае это только что созданная таблица CLIENTS:


Рис.14. Выбор master-таблицы

Затем определим, какие поля этой таблицы нам нужны (можно выбрать все), и как они будут расположены на форме (выберем горизонтальное расположение полей). Затем определим detail-таблицу (в данном случае HOLDINGS), выберем все поля и в качестве способа их отображения выберем размещение их в TDBGrid. Наконец, укажем, что таблицы связаны по полю ACCT_NBR:


Рис.15. Установка связи между таблицами

Далее выбираем опцию Generate a Main Form и в результате получим форму, похожую на представленную на рис. 16:


Рис.16. Вот что обычно получается при использовании Database Form Wizard

После редактирования и открытия таблиц, изменения размеров формы и панелей, а также замены компонента TDBEdit, отображающего поле IMAGE, на TDBimage, получим форму, похожую на рис.17:


Рис.17. Главная форма приложения после "приведения в порядок"

Скомпилируем и запустим созданное приложение и рассмотрим, каким образом созданная информационная система реагирует на изменение данных.

Если мы попытаемся удалить первую запись в таблице CLIENTS, нам это удастся, несмотря на то, что в таблице HOLDINGS есть связанные с ней записи. Точно так же можно добавить запись с произвольным значением поля ACC_NBR в таблицу HOLDINGS, и это нам также удастся. Таким образом, в созданной нами базе данных из двух таблиц связь "один-ко-многим" фактически отсутствует.

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

Перенос унаследованных данных с использованием CASE-средств

Рассмотрим альтернативный способ переноса данных на сервер, более дорогой и сложный, но приводящий в целом к более качественному результату. Этот способ базируется на использовании CASE-средств (CASE расшифровывается как Computer-Aided System Engineering) для восстановления схемы базы данных по имеющимся таблицам (так называемого обратного проектирования), замены платформы и описания связей между таблицами с точки зрения реакции сервера на попытки того или иного изменения данных со стороны клиентского приложения. В качестве такого средства рассмотрим, например, ERwin 3.0 - CASE-средство компании Logic Works, предназначенное для проектирования баз данных и на сегодняшний день являющееся одним из наиболее простых и доступных по цене средств такого класса.

Прежде чем заняться обратным проектированием, следует описать ODBC-источник, соответствующий каталогу, в котором хранятся исходные dBase-таблицы (это делается с помощью панели управления Windows).


Рис.18. Описание ODBC-источника с помощью панели управления Windows

Попробуем осуществить обратное проектирование с помощью ERwin , используя созданный ODBC-источник. Для этого из меню главного окна ERwin выберем опцию Tasks/Reverse Engineering .

Первая проблема, с которой при этом можно столкнуться, заключается в том, что Erwin не поддерживает формат данных dBase 5.0 (с прежними версиями dBase такой проблемы нет), и при обратном проектировании структура таблиц, содержащих графические поля, не всегда восстанавливается. Обычно эта проблема решается путем выбора сходной по структуре платформы (dBase III, Clipper, FoxPro) и последующей коррекции результатов обратного проектирования. Особое внимание при этом следует обращать на специфические типы данных (например, BLOB-поля), так как различия между платформами заключаются, в частности, в способах хранения подобных типов данных (но, разумеется, не только в этом).

Выберем в качестве исходной платформы Clipper, ответим на вопросы, предлагаемые в последующем диалоге (можно оставить то, что предложено по умолчанию) и в результате получим модель данных, похожую на изображенную на рис.19 (она содержит описание всех dBase-таблиц из каталога, содержащего данные для примеров, поставляемых с C++Builder):


Рис.19. Результат обратного проектирования каталога CBUILDER\EXAMPLES\DATA

Отредактируем полученную модель данных, убрав все таблицы, кроме CLIENTS и HOLDINGS, определив ACC_NBR первичный ключ таблицы CLIENTS и изменив тип данных поля IMAGE на МЕМО (опция Column Editor контекстного меню таблицы). Создадим также неидентифицирующую связь "один-ко-многим" между таблицами CLIENTS и HOLDINGS, выбрав для этой цели соответствующую пиктограмму на "плавающей" инструментальной панели.

Далее следует выбрать другую целевую платформу (в нашем случае Oracle). В результате получим примерно следующий вид модели данных:


Рис.20. Примерный вид модели данных для генерации БД в Oracle

Теперь можно описать свойства имеющейся связи между таблицами. Так как это связь "один-ко-многим", это следует явно указать в диалоге, вызываемом с помощью опции Relationship Editor контекстного меню связи. В том же диалоге на другой странице трехстраничного блокнота следует выбрать из предлагаемых выпадающих списков возможную реакцию сервера на попытки нарушения ссылочной целостности со стороны клиента. Например, при попытке удалить запись из таблицы CLIENTS можно либо совершить каскадное удаление (то есть удалить все соответствующие записи из таблицы HOLDINGS), либо запретить удаление, если имеются соответствующие записи в дочерней таблице, с выдачей диагностического сообщения.


Рис.21. Определение реакции сервера на попытки нарушения ссылочной целостности

После этого можно выбрать из меню опцию Tasks/Forward Engineer/Schema Generation и после установки соединения с Oracle сгенерировать базу данных, выбрав в появившейся диалоговой панели опции для генерации структуры. Можно также просмотреть и сохранить скрипт на языке PL/SQL (это процедурное расширение SQL, используемое для написания триггеров и хранимых процедур Oracle), называемый также DDL-сценарием (DDL расшифровывается как Data Definition Language).


Рис.22. DDL-сценарий генерации схемы базы данных

Далее можно попытаться снова воспользоваться Data Migration Wizard для переноса данных, отказываясь при этом от удаления уже сгенерированных таблиц. Однако в ряде случаев удобнее создать приложение для переноса данных из старой БД в новую. Как было отмечено выше, унаследованные данные могут не удовлетворять правилам ссылочной целостности, установленным на сервере. В этом случае от приложения, используемого для переноса данных, требуется некоторая гибкость (например, предоставление возможности редактирования исходных данных или создание дополнительных таблиц, содержащих записи, не удовлетворяющие бизнес-правилам новой базы данных, для последующего анализа).

Создадим простейшее приложение для переноса данных. Для этого создадим форму следующего вида (рис.23):


Рис.23. Форма приложения для переноса данных на сервер

Для переноса данных с одной платформы на другую обычно используется компонент TBatchMove. Этот компонент обеспечивает копирование данных из одной таблицы в другую. Основные свойства этого компонента следующие: Source – таблица (или запрос), откуда копируются данные, Destination – таблица, куда копируются данные, Mapping – определяет соответствие между колонками исходной и результирующей таблиц (для идентичных таблиц это свойство определять не обязательно), Mode – тип перемещения (batAppend – добавляет новые строки в результирующую таблицу, batUpdate – заменяет строки в результирующей таблице на соответствующие строки оригинала, batCopy – копирует строки в результирующую таблицу, переписывая ее, batDelete – удаляет записи в результирующей таблице, соответствующие записям оригинала), KeyViolTableName и ProblemTableName – имена дополнительных таблиц для помещения записей, чье копирование запрещено правилами ссылочной целостности или по каким-либо причинам невозможно (например, из-за несоответствия типов данных), ChangedTableName – имя таблицы для помещения измененных записей. Копирование данных происходит при выполнении метода Execute(). Отметим, что этот метод может быть вызван непосредственно из среды разработки с помощью контекстного меню компонента TBatchMove.

Установим следующие значения свойств используемых компонентов:

Компонент

Свойство

Значение

Table1

DatabaseName

Oracle7

Exclusive

true

TableName

CLIENTS

Active

true

Table2

DatabaseName

BCDEMOS

TableName

ClLIENTS.DBF

Active

true

DataSource1

DataSet

Table1

DataSource2

DataSet

Table2

DBGrid1

DataSource

DataSource1

DBGrid2

DataSource

DataSource2

DBNavigator1

DataSource

DataSource1

DBNavigator2

DataSource

DataSource2

BatchMove1

Source

Table2

Destination

Table1

Mode

batAppend

Button1

Caption

CLIENTS

Button2

Caption

HOLDINGS

Button3

Caption

Добавить

Button4

Caption

Очистить

Button5

Caption

Выход

Создадим также обработчики событий для кнопок:

//--------------------------------------------------------

#include

#pragma hdrstop

#include "upsize1.h"

//--------------------------------------------------------

#pragma link "Grids"

#pragma resource "*.dfm"

TForm1 *Form1;

//--------------------------------------------------------

__fastcall TForm1::TForm1(TComponent* Owner): TForm(Owner)

{

}

//--------------------------------------------------------

void __fastcall TForm1::Button1Click(TObject *Sender)

{

Table1->Close();

Table2->Close();

Table1->TableName="CLIENTS";

Table2->TableName="CLIENTS.DBF";

Table1->Open();

Table2->Open();

}

//--------------------------------------------------------

void __fastcall TForm1::Button2Click(TObject *Sender)

{

Table1->Close();

Table2->Close();

Table1->TableName="HOLDINGS";

Table2->TableName="HOLDINGS.DBF";

Table1->Open();

Table2->Open();

}

//--------------------------------------------------------

void __fastcall TForm1::Button5Click(TObject *Sender)

{

Table1->EmptyTable();

}

//--------------------------------------------------------

void __fastcall TForm1::Button3Click(TObject *Sender)

{

BatchMove1->Execute();

}

//--------------------------------------------------------

void __fastcall TForm1::Button4Click(TObject *Sender)

{

Close();

}

//--------------------------------------------------------

Скомпилируем и запустим приложение. Кнопки CLIENTS и HOLDINGS осуществляют выбор между той или иной парой таблиц. При нажатии кнопки Добавить происходит перенос данных из активной в данный момент таблицы dBase (CLIENTS или HOLDINGS) в соответствующую таблицу Oracle. Отметим, что наличие поддержки ссылочной целостности можно проверить, попытавшись перенести данные из таблицы HOLDINGS до того, как перенесены данные из таблицы CLIENTS. При этом перенос осуществлен не будет, и в процессе выполнения приложения появится диагностическое сообщение примерно следующего вида (рис.24):



Рис.24. Диагностическое сообщение при попытке добавления записей в detail-таблицу при пустой master-таблице.

Примерно такие же последствия будет иметь попытка очистить таблицу CLIENTS после того, как перенесены записи в таблицу HOLDINGS.

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

Теперь, если мы попытаемся удалить запись из таблицы CLIENTS при наличии связанных с ней записей в таблице HOLDINGS, нам это не удастся. При этом клиентским приложением будет выдано диагностическое сообщение о наличии записей в дочерней таблице (рис. 25):


Рис.25. Диагностическое сообщение при попытке удаления записей из master-таблицы при наличии связанных с ней записей в detail-таблице.

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

Разумеется, пользователь приложения должен видеть нечто более вразумительное, нежели англоязычное сообщение с именем триггера и словами про "integrity constraint" и "key violation". Можно сделать это путем перехвата исключения в клиентском приложении, но более предпочтительно делать это на сервере, так как тогда будет исключена необходимость в повторении кода в случае, когда с одной и той же базой данных работают несколько приложений. Современные CASE-средства позволяют это сделать, и интересующиеся этой проблемой могут найти ее решение в документации по используемому CASE-средству и в документации, прилагаемой к соответствующему серверу баз данных.

Некоторые выводы

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

© Рефератбанк, 2002 - 2024