Основная экранная форма

¨ Количество товара на складе:= Количество товара на складе – Количество купленного товара.

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

Для первого случая поступим следующим образом:

§ Во первых, свяжем эти таблицы операционной связью (Relation, Link, Master-Detal) так, чтобы таблица «Товары» всегда была позиционирована на том товаре, который продается согласно текущей строке таблицы «Расход товара». Это позволит «всегда иметь под рукой» цену продаваемого товара.

Для этого установим у объекта TovaryTable (типа TTable) значение свойства MasterSource равным DataSource3 (который управляет таблицей Rasxod через объект RasxodTable) и значение свойства MasterFields (после щелчка на кнопку «...» появится окно редактора связей, в котором надо выбрать ключи связи KOD_TOVAR->KOD_TOVAR). Объявленная связь сразу проявится – DBGrid1 будет показывать только строку таблицы «Товары», соответствующую текущей строке в «Расход товара»[16].

Аналогично можно связать ведомую (Detal-)таблицу «Покупатели» с ведущей (Master-)таблицей «Расход товара».

§ Теперь для события OnDataChange объекта DataSource3 напишем обработчик[17]

§

При этом естественно значение свойства ReadOnly столбца Stoim объекта DBGrid3 положить равным True, чтобы запретить независимые корректировки этого реквизита. С этой целью необходимо дважды щелкнуть мышью на объекте DBGrid3, вызвать редактор столбцов и манипулируя левой кнопкой мыши получить доступ ко всем столбцам, в появившемся списке выбрать столбец, характеризующий стоимость и в свойстве ReadOnly выбрать значение True.

§ Остается еще один случай, в котором не обеспечено корректное обновление значение поля «стоимость» - при изменении цены товара в таблице «Товары». Для этого добавим в БД триггер:

CREATE TRIGGER AU_TOVARYI FOR TOVARY AFTER UPDATE POSITION 2

AS BEGIN

IF (OLD.ZENA <> NEW.ZENA) THEN

UPDATE RASXOD SET STOIM=NEW.ZENA*KOLVO

WHERE KOD_TOVAR = OLD.KOD_TOVAR; END

Появление значения OLD.KOD_TOVAR (а не NEW.KOD_TOVAR) в строке условия отбора оператора UPDATE вызвано необходимостью корректно обрабатывать ситуацию, когда одновременно меняются код товара и его цена. Это означает, что системное каскадное обновление выполняется после выполнения триггера AU_TOVARYI, а не до (как казалось...).

Теперь установим контроль условия KOLVO>=0 – обработчик события OnValidate поля Kolvo объекта RasxodTable:

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

Прежде чем двигаться дальше, полезно посмотреть поведение программы в действии:

§ Как отрабатывает каскадное обновление таблицы «Расход товара» при удалении строки и изменении кода товара в таблице «Товары». Аналогично, для таких же операций с таблицей «Покупатели», ведь реализация каскадного обновления в этих двух случаях разная.

§ Как отрабатывает контроль ограничений целостности в таблице «Расход товара» при изменении кодов товара или покупателя на отсутствующие в родительских таблицах.

§ Как отрабатывает контроль условия ZENA>=0 и условия KOLVO>=0.

Обратите внимание: реакция на нарушение первого условия появляется только после попытки покинуть текущую строку таблицы, а для второго условия реакция почти мгновенная – программа не позволяет покинуть поле.

Это связано с тем, что второе условие контролирует Delphi-программа, причем именно в момент выхода из поля[18]. А первое условие контролирует InterBase SQL-сервер, причем только после попытки покинуть текущую строку таблицы – только в этот момент Delphi-программа подтверждает изменения (вызывая метод Post) и посылает запрос InterBase SQL-серверу на проведение соответствующих изменений в реальной таблице.

§ Как отрабатывает перерасчет «стоимости» при изменении вместе и по отдельности «количества» и «кода товара» в таблице «Расход товара», а также изменении цены товара в таблице «Товары».

§ Как отрабатывает перерасчет «количества на складе» при таких же изменениях в таблице «Расход товара». И как не выполняется этот перерасчет при изменении «кода товара» в таблице «Товары» и каскадном его изменении в таблице «Расход товара».

§ Как отрабатывает перерасчет «количества на складе» при удалении и добавлении строк в таблице «Расход товара». И как при добавлении отрабатывает генератор «кода покупки».

Теперь внесем в нашу программу еще несколько изменений...\PRG1\SKLAD.DPR

Объявленная нами связь «Detal-ведомая -> Master-ведущая» для таблиц TOVARY->RASXOD ограничила область видимости в Grid таблицы «Товары»[19]. Пока мы работаем в Grid таблицы «Расход товара» это возможно даже и очень удобно. Но когда мы переключаемся на Grid таблицы «Товары» хотелось бы видеть весь список товаров. Для устранения этих проблем:

§ Поместим на экранную форму еще один объект типа TTable, управляющий таблицей TOVARY, и объект типа TDataSource, управляющий ее связью с объектом DBGrid1.

Это легче сделать копированием – щелчок на копируемом объекте, CTRL+C, CTRL+V и мышкой переместить выделенную копию «в сторонку» (осторожно! копия получается точно наложенной на оригинал, но при её перемещении оригинал останется на месте).

§ Установим имя Name TovaryTable1 у нового объекта типа TTable, а у нового объекта типа TDataSource оставим имя DataSource4, предложенное системой, и на всякий случай проверим, что DataSource4 действительно ссылается (в смысле DataSet =) на TovaryTable1. Теперь разграничим функции объектов TovaryTable и TovaryTable1: пусть за связь Master-Detal с таблицей «Расход товара» отвечает TovaryTable1, а за остальное – TovaryTable.

§ У объекта TovaryTable: удалим значения свойств MasterSource, MasterFields и IndexFieldName.

§ У объекта TovaryTable1: удалим вызов обработчиков событий AfterInsert и AfterPost (но не сами процедуры обработки, т.к. они вызываются в объекте TovaryTable).

§ У объекта DataSource3 (связь с таблицей «Расход товара») внесем изменение в обработчик события OnDataChange: в процедуре DataSource3DataChange заменим

TovaryTable.FieldByName('Zena') на TovaryTable1.FieldByName('Zena').

§ Теперь обеспечим переключение так, чтобы таблицей «Товары» управлял объект TovaryTable, когда курсор находится в DBGrid1 таблицы «Товары», и объект TovaryTable1, когда курсор находится в DBGrid3 таблицы «Расход товара».

Для этого внесем изменения в текст обработчика события OnEnter объекта DBGrid1: в процедуру DBGrid1Enter[20] (в начало) добавим

Далее поправим обработчик события OnEnter объекта DBGrid3: в процедуру DBGrid3Enter (в начало) добавим

Аналогичные преобразования надо провести для таблицы «Покупатели» и её связи с таблицей «Расход товара». Теперь мы будем видеть полный список товаров и покупателей в своем «окне просмотра», а находясь в окне просмотра «Расход товаров» будем видеть информацию только о текущем товаре и покупателе. Причем сохранится правильность расчета стоимости продажи, которая существенным образом основана на связи Master-Detal.

Мы убедились, что при добавлении записей генераторы правильно формируют коды соответствующих элементов таблиц. Можно заметить, что значение полей, описывающих эти коды и необходимых для обеспечения уникальности записей, не носят содержательный характер, и могут быть исключены из состава столбов визуальной компоненты TDBGrid. Также желательно наименования столбцов таблиц выводить на русском языке. Для исключения столбца из состава столбцов визуальной компоненты необходимо выбрать мышью объект DBGrid1, в инспекторе объектов найти свойство Columns, открыть окно редактирования столбцов, через контекстное меню создать список, включающий все поля таблицы (далее можно удалить ненужные столбцы из списка). Каждый столбец, являясь объектом, имеет ряд свойств. Для изменения наименования столбца необходимо исправить для каждого поля свойство Caption, входящее в список подсвойств свойства Title.

Записи в Таблице «Расход товара» не содержат наименований товаров и покупателей, а содержат только коды этих реквизитов. Поскольку код товара не несет содержательной информации, а конечный пользователь привык работать с наименованием товара, желательно при показе таблицы «Расход товара» выводить на экран не коды товара и покупателя, а их наименования. Этого можно достичь, используя поля выбора данных(LookUp-поля). Создадим LookUp-поле для наименования товара. [21] Выберем мышью иконку компоненты Ttable для таблицы «Расход товара» и двойным щелчком вызовем пустой список полей таблицы. Вызвав правой кнопкой мыши контекстное меню, выберем режим добавления всех полей, а также режим добавления нового поля. Появившуюся форму необходимо заполнить, как показано ниже

На данном экране описана LookUp-связь по ключевому полю KOD_TOVAR с таблицей «Товары». В результате всех этих действий в таблице «Расход товара» образуется новое текстовое поле TOVAR, которое связано по полю KOD_TOVAR с соответствующим полем таблицы «Товары». Совершенно аналогично поступим с полем POKUP. В столбцах компоненты DBGrid3 появляются элементы ComboBox (с наименованием товара и покупателя) через которые можно осуществить выбор значения соответствующего реквизита.

Набор значений полей может быть организован также через компоненты DBText, DBEdit, DBMemo, DBListBox, DBComboBox, DBCheckBox, DBRadioGroup, DBLookUpComboBox и пр. В каждом из этих элементов необходимо настроить свойства DataSource и DataField. [22]

[1] Ключевые поля в таблицах выделены подчеркиванием.

[2] Резервное копирование, вообще говоря, является функцией администратора базы данных, поэтому выполнение этой функции может потребовать соответствующих прав доступа.

[3]) Параметр CHARACTER SET WIN1251 можно опустить, он будет устанавливаться по умолчанию для символьных полей, т.к. ссылка на эту кодировку символьных данных была задана при создании базы данных. Опускать значение параметра COLLATE не рекомендуется, по умолчанию оно может установиться совсем не так, как ожидалось.

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

[5] Такая ситуация называется нарушением условия целостности базы данных.

[6] Вообще говоря, можно было при проектировании базы данных не включать поле «Стоимость купленного товара» в таблицу RASXOD, поскольку при необходимости эти значения вычисляются с использованием данной формулы. В нашем примере данное поле присутствует из желания продемонстрировать требования к целостности базы данных и механизм поддержки целостности.

[7] Товар был куплен по ошибке и обменен на другой товар

[8] Обращение к этим процедурам оставлено клиентской части программы

[9] поскольку этот алиас является внешним и доступен через администратор

[10] Этот компонент представляет набор данных, построенный на базе одной физической таблицы

[11] При работе с удаленными базами данных рекомендуется использовать компонент TQuery.

[12] Внимание! При переносе кода в С++ необходимо учитывать отличия в синтаксисе, которые связаны с доступом к полям структуры, оформлением наименований полей (строки в С++ оформляются двойными кавычками, символы - одинарными) и традиционными различиями оформлений оператора присваивания.

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

[14] В случае программирования в среде Borland_C++ необходимо соответственно писать Table1->First, Table1->Last, Table1->Next, Table1->Prior

[15] Навигация по таблице, вообще-то говоря, разрешена лишь в определенных состояниях (например, не разрешена в режиме редактирования или вставки записи). Эти состояния можно отследить, проверяя значение свойства State. Более правильным является код:

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

[16] Вообще-то мы уже связывали эти таблицы, причем именно так же, при определении базы данных в WISQL. Однако смысл тех действий – определить ограничения целостности (требования правильности) БД, а смысл объявления операционной связи (Relation) – обеспечить соответствующее перемещение маркера текущей записи в таблице «Товары» при перемещении маркера текущей записи в таблице «Расход товара».

[17] Простое действие «Стоимость:=Количество*Цена», пришлось обложить проверкой условия, причем довольно деликатной:

§ Событие OnDataChange случается гораздо чаще, чем нужно выполнять интересующее нас действие.

§ Это интересующее нас действие можно выполнять, только если таблица «Расход товара» находится в состоянии, допускающем ее обновление (State=dsEdit,dsInsert).

§ Однако самое деликатное – необходимость устранить возможность рекурсивного вызова. Событие OnDataChange почти последнее в цепочке действий, реализующих последствия изменений в строке (значения поля Kolvo или KOD_TOVAR, а значит Zena). Поэтому естественно, что наше действие, изменяющее значение поля Stoim, опять инициирует эту цепочку действий...

Возможно наиболее естественным и аккуратным было бы использование события OnChange поля Kolvo и Kod_Tovar объекта RasxodTable. Но к сожалению это событие происходит раньше, чем успевает установиться новая соответствующая строка в таблице Rasxod (с соответствующей ценой) при изменении значения поля Kod_Tovar и это влечет неправильное вычисление стоимости.

[18] Другой вариант поручить этот контроль клиенту - установить свойство CustomConstraint поля Kolvo объекта RasxodTable равным Kolvo>=0, а свойство ConstraintErrorMessage равным: "Количество" должно быть неотрицательным. Заметим, что условия прописанные в процедуре вызывающуюся по событию On Validate проверяются раньше проверки условий, прописанных в условии CustomConstraint.

[19] Если эту связь определить в обратную сторону, то получим аналогичный двойственный результат, но… для правильного вычисления стоимости нам нужна связь именно та, какая определена.

[20] Как выяснилось, использовать обработчик событий DBGrid1.OnEnter для переключения таблиц необходимо с определенной долей осторожности. Этот метод отрабатывает при установке фокуса на соответствующий Grid (в частности, для Grid1 при активизации формы). Поскольку открытие базы данных и открытие формы происходит параллельно, то в зависимости от ресурсов компьютера (в частности, скорости его работы), открытие базы данных может произойти после отрабатывания данного метода. В этом случае при открытии формы выполнение оператора TovaryTable.Refresh создаст исключительную ситуацию. Обойти это можно или добавлением проверки открыта ли база данных, или использованием другого обработчика (например, OnCellClick, этот метод отрабатывает только при установки фокуса на некоторую ячейку компонента Grid мышью, правда, в этом случае возникают новые проблемы: щелчок на заголовок Grid не даст необходимого эффекта)

[21] Добавление Look-Up-поля можно делать только при закрытых таблицах.

[22] Такая реализация работы с полями выбора (LookUp-поля, DBListBox, DBComboBox, DBLookUpComboBox) может создавать побочные эффекты: Эти объекты используют таблицу в качестве списка выбора, в рассмотренном случае – это таблица TOVARY, управляемая объектом TovaryTable (типа TTable). Проблема может возникать из-за того, что с этим же объектом TovaryTable связан объект DBGrid1 (через DataSource1). Перемещение к следующей записи в DBGrid1 («Товары») одновременно означает перемещение по списку выбора... с не очень ясными последствиями... Похоже, в нашем примере побочные эффекты не наблюдаются...

Устранить возможность побочного эффекта можно, поместив на форму еще один объект типа TTable, совпадающий с TovaryTable, но с другим именем, например TovaryTCombo, и установив в LookUp-поле TOVAR значение свойства LookUpDataSet равным TovaryTCombo.

Что хорошего и плохого в том, что для управления доступом к одной и той же таблице TOVARY используется несколько объектов типа TTable? Эта ситуация означает, что мы можем открыть для доступа несколько экземпляров одной и той же таблицы – данные в них одни и те же (и вообще говоря не дублируются), но положение маркера текущей записи разное. При этом, естественно мы имеем дополнительные расходы памяти на управляющую информацию, но зато имеем возможность безопасно (и без хлопот) обрабатывать записи одной и той же таблицы одновременно по нескольким разным схемам.