526______________________________________________Глава 9

else
(

Application->MessageBox("Ошибочные данные","Ошибка",MB_ICONSTOP) ;

Abort() ;

К этому обработчику будет происходить обращение перед выполнением метода
Post, как бы он не был вызван: явно или вследствие перемещения по базе данных,
если текущая запись была изменена. В обработчике сначала производится провер-
ка данных в записи. Если она дает неудовлетворительный результат, то пользова-
телю дается сообщение об ошибочности данных и выполняется функция Abort, пре-
рывающая выполнение Post. Текущая запись остается в состоянии dsEdit, но оши-
бочные данные в ней не сбрасываются, что позволяет пользователю исправить их.

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

В операторе Cancel использована ссылка DataSet. Это параметр, передавае-
мый в обработчик события BeforePost и соответствующий набору данных, к кото-
рому применяется Post. Использование параметра DataSet позволяет написать об-
работчик в более общем виде и к такому обработчику можно обращаться при собы-
тиях в разных наборах данных. Для конкретизации вместо DataSet можно было
бы использовать имя конкретного набора данных, например, Tablel.

Таким образом, приведенный выше обработчик события BeforePost позволяет
предотвратить непроизвольное или ошибочное изменение данных.

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

9.11.3 Кэширование изменений

По умолчанию все изменения в наборе данных, завершаемые методами Post,
Insert, Delete и т.п., заносятся в базу данных. Однако, возможен и другой режим
работы, при котором все изменения, вносимые пользователем в записи, кэшируют-
ся — т.е. сохраняются в памяти локально. В этом случае пользователь работает не
с реальными данными, а с их копиями. И только по специальной команде все вне-
сенные пользователем изменения заносятся в базу данных.

Режим кэширования определяется свойством CachedUpdates компонента
Table. По умолчанию это свойство равно false и кэширование не производится.
Если установить его в true, то все изменения набора данных будут кэшироваться.
Они передаются в базу данных только после выполнения метода Apply Updates.
Если же после множества изменений выполнить метод CancelUpdates, то все изме-
нения, произведенные после последнего выполнения ApplyUpdates, отменяются.

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