Вы уже изучили основные принципы обновления содержимого БД с использованием отложенных изменений, хранящихся в объекте DataSet. Если вы генерируете собственную логику1 обновления (в форме запросов INSERT, UPDATE и DELETE или вызовов хранимых процедур), вам необходимо знать больше, чем просто основы. Например, как управлять параллелизмом, чтобы случайно не перезаписать изменения, сделанные другим пользователем?

Как обрабатывать значения NULL при управлении параллелизмом?

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

Что произойдет? Это зависит от структуры обновляющих запросов. Предлагается четыре основных способа оптимистичного управления параллелизмом. Использование только полей первичного ключа В SQL-запросы UPDATE и DELETE можно включать только поля первичного ключа; при этом возникает ситуация побеждает пришедший последним. Обе попытки обновления завершатся успешно.

Понятно, что БД не способна поддерживать оба набора обновлений. Должен остаться лишь один. Изменения, сделанные первым пользователем, будут переопределены изменениями, внесенными последним пользователем. Вот кратко последовательность действий при возникновении подобной си туации: • пользователь А выбирает запись; • пользователь Б выбирает запись; • пользователь Б изменяет запись и успешно передает изменения; • пользователь А изменяет запись и успешно передает изменения, перезаписывая изменения, внесенные пользователем Б. Пользователь А даже не знает, что в период времени между выполнением исходного запроса и передачей обновлений в БД соответствующая запись БД была изменена другим пользователем. Если ситуация побеждает пришедший последним —именно то, что вам нужно, данный способ управления параллелизмом подойдет вам. Однако когда требуется исключить возможность непреднамеренной перезаписи чужих изменений другими пользователями, этот способ неприемлем. В отличие от мастера Data Adapter Configuration Wizard, объект CommandBuilder не предоставляет такого варианта оптимистичного управления параллелизмом.

Рейтинг пользователей: / 0
ХудшийЛучший