Свойство UpdateMode и обновление записей
Уровни изоляции транзакций определяют, что происходит, когда одна транзакция изменила данные и не подтвердила изменения, а вторая транзакция в это время читает или записывает те же данные.
Возможна также и ситуация, когда транзакция А стартовала и не вносила изменений на момент старта транзакции В. После старта транзакции В, А изменила данные и подтвердила изменения. Затем транзакция В внесла изменения и пытается их подтвердить.
Что произойдет в этом случае?
Чтобы ответить на этот вопрос, следует изучить режимы, указываемые в свойстве UpdateMode набора данных в приложении клиента - специально для разрешения подобных ситуаций.
Приложение изменяет копию записи в локальном НД на компьютере, где выполняется клиентское приложение. После выдачи подтверждения корректировки происходит отправка к серверу БД запроса на изменение значений существующей в ВД записи на новые значения, внесенные приложением в локальную копию. Для этого сервер должен найти в БД запись, которая еще сохраняет свои старые, неоткорректированные значения. По существу сервер пытается выполнить оператор UPDATE, где в предложении WHERE перечислены старые значения полей.
Если запись, которую пытается изменить сервер, уже была изменена другой транзакцией, операция UPDATE не пройдет из-за того, что записи со старыми значениями в БД физически не существует.
Свойство набора данных
property UpdateMode;
определяет, по каким полям ищется запись на сервере для обновления.
Возможные значения этого свойства:
• WhereAII (по умолчанию) - поиск записи, которая должна быть физически изменена, ведется по всем полям;
• WbereKeyOnly - поиск записи ведется только по значениям ключевых полей;
• WhereChanged - поиск ведется по ключевым полям и по тем из неключевых полей, которые были изменены при корректировке записи в приложении.
Наиболее жесткое условие поиска - WhereA II. Оно предотвращает запоминание изменений, внесенных в запись, если конкурирующая транзакция успела изменить хотя бы одно поле и подтвердить это изменение. Менее жесткое условие - WhereChanged. Оно предотвращает запоминание изменений, внесенных в запись, если конкурирующая транзакция успела изменить хотя бы одно ключевое поле или поле, которое было изменено и текущей транзакцией. Вероятность ошибок при этом выше, чем при WhereAll. Наименее жесткое и с наибольшей вероятностью ведущее к ошибке условие - WhereKeyOnly. Оно предотвращает запоминание изменений, если конкурирующая транзакция успела изменить хотя бы одно ключевое поле, которое пытается также изменить и текущая транзакция. Изменения других полей в расчет не принимаются.
Таким образом, если две или более конкурирующие транзакции пытаются осуществить корректировку одной и пой же записи, срабатывает правило:
подтверждаются изменения, внесенные транзакцией, которая раньше других успела их подтвердить; остальные изменения не запоминаются и возбуждается исключение.
| Firma | Familia | Doljnost | Oklad |
| Янтарь | Ивонов | Директор | 1000 |
Пример.
Пусть в ТБД, состоящей из 4 полей (столбцов): Firma, Familia, Doljnost и Oklad, две транзакции из разных приложений пытаются изменить запись| Firma | Familia | Doljuost | Oklad |
| Янтарь | Иванов | Директор | 2000 |
Пользователь А и В оба знают, что эти данные недостоверны. Во-первых, Ивонов не директор, а бухгалтер. А Иванов — действительно директор -получает не 1000, а 2000. 1000 получает Ивонов. Поэтому каждый из пользователей А и В решает изменить запись. Пусть пользователь А изменил фамилию на 'Иванов', а оклад на 2000 и подтвердил транзакцию. Запись была изменена так:
Несколько мгновений спустя пользователь В изменил должность на 'Бухгалтер' и также подтвердил транзакцию:
| Firma | Familia | Doljnost | Oklad |
| Янтарь | Ивонов | Бухгалтер | 1000 |
Однако записи ['Янтарь'; 'Ивонов'; 'Бухгалтер'; 1000] физически не существует.
