INTEGRITY

Синтаксис

CONST
 INTEGRITY_OFF = 0;
 INTEGRITY_ON  = 1; 

Описание

Набор именованных констант атрибута INTEGRITY TRY-блока. Константы определяют режим контроля целостности данных.

• INTEGRITY_OFF - отключить контроль
• INTEGRITY_ON - включить контроль

Контроль целостности работает при выполнении процедур модификации INSERT, REPLACE, REMOVE, REMSEL, а также FREEZE, DEFROST, FREEZESEL, DEFROSTSEL, и относится только к регулярным файлам. Если, например, в качестве параметра REPLACE указан регулярный файл БД, при включенном контроле целостности будут модифицированы связанные записи регулярных USER- и BORROW-файлов, но не будут модифицированы связанные записи подключаемых USER- и BORROW-файлов. Если же процедура выполняется для подключаемого файла, независимо от режима контроля целостности будет модифицирована только запись указанного файла.

Влияние контроля целостности:

1. REPLACE модифицирует связанные записи всех транзитивных BORROW- и USER- файлов
2. REMOVE удаляет связанные записи всех транзитивных BORROW-файлов
3. FREEZE, DEFROST обрабатывают связанные записи всех двойных транзитивных BORROW-файлов
4. (INSERT, REPLACE) исключение 220, если значение поля вставляемой записи (при REPLACE нового экземпляра записи), входящего в связь со справочным файлом, имеет непустое значение, отсутствующее в справочном файле
5. (INSERT, REPLACE) исключение 217, если вставляемая запись (при REPLACE новый экземпляр записи) ссылается на справочную запись, не удовлетворяющую файловому фильтру
6. (REPLACE, REMOVE, FREEZE, DEFROST) исключение 219, если исходный экземпляр записи ссылается на несуществующую запись справочного файла
7. (REPLACE, REMOVE, FREEZE, DEFROST) исключение 218, если исходный экземпляр записи ссылается на справочную запись, не удовлетворяющую файловому фильтру
8. (INSERT, REPLACE, REMOVE, FREEZE, DEFROST) исключение 981, если исходный или новый экземпляр записи иерархически ссылается на родительскую запись, которая не является контейнером
9. (REPLACE, REMOVE, FREEZE, DEFROST) исключение 224, если пользователь не имеет прав чтения (Scan) на один из транзитивных BORROW- и USER- файлов, имеющих записи, связанные с обрабатываемой. А если нет права модификации, т.е. права Replace при выполнении REPLACE, права Remove при выполнении REMOVE, то исключение 352, а отсутствие права архивации (ArcWrite) при FREEZE, DEFROST - исключение 226
10. (REPLACE) исключение 394, если поле, входящее в связь с USER- и BORROW-файлами, основанную не на автоинкрементном индексе, меняет значение с непустого на пустое
11. (REMOVE) исключение 223, если существует связанные записи USER-файла (не BORROW)

Выполнение REMSEL, FREEZESEL и DEFROSTSEL с точки зрения контроля целостности можно рассматривать как последовательное выполнение соответственно REMOVE, FREEZE и DEFROST.

Версионность при работе контроля целостности:

1. наличие справочных записей к исходному экземпляру записи проверяется
   1. на собственном срезе, если исходная запись была получена в мягком режиме
   2. на последнем завершенном срезе, если в жестком
2. наличие справочных записей для нового экземпляра записи проверяется на последнем завершенном срезе с условием, что справочные записи не были модифицированы незавершенными транзакциями.
3. поиск связанных записей в BORROW- и USER-файлах выполняется во всех перечисленных срезах:
   1. на последнем завершенном срезе. Это понятно, т.к. именно он и представляет набор самых свежих данных.
   2. на срезах всех незавершенных транзакций. Предположим незавершенная транзакция выполнила вставку новой записи в BORROW-файл. Понятно, что REPLACE записи LEND-файла в нашей пусть даже мягкой транзакции обязан заметить наличие этой вставленной записи и выдать конфликт блокировки при попытки выполнить REPLACE этой связанной записи BORROW-файла. Если эту запись не заметить, то когда та транзакция завершится, появится "ничейная" BORROW-запись.
   3. а если транзакция имеет базовый срез, то еще и на собственном срезе. Предположим транзакция, завершенная после начала нашей, удалила запись BORROW-файла. Если REPLACE записи LEND-файла в нашей мягкой транзакции не заметит, что на нашем базовом срезе такая запись была, то он просто модифицирует оставшиеся связанные записи BORROW-файла. Но потом наша программа, работающая на мягкой транзакции, с огромным удивлением может обнаружить "ничейную" BORROW-запись, продолжающую жить на базовом срезе. Чтобы этого не произошло, записи просматриваются с учетом базового среза. Все то же самое относится и к жестким транзакциям, имеющим базовый срез, т.к. в любой момент может быть переключение в мягкий режим всей транзакции или отдельного файла, а значит описанная проблема может проявиться.

Даже при выключенном контроле целостности проверяется наличие справочных записей у нового экземпляра INSERT и REPLACE, если справочный файл находится в SOFT-режиме. Например, в следующем фрагменте

IF SEARCH(Owner ...) THEN
 User.Owner:= Owner.Owner;
 REPLACE(User);
END;

программа с помощью SEARCH убедилась в существовании справочной записи. Но справочная запись, существующая на собственном срезе, уже возможно уничтожена на завершенном. В этом случае выбрасывается исключение 967.