Информационный сайт

 

Реклама
bulletinsite.net -> Книги на сайте -> Вебмастеру -> Сеппа Д. -> "Microsoft ADO.NET" -> 167

Microsoft ADO.NET - Сеппа Д.

Сеппа Д. Microsoft ADO.NET — М.: Русская Редакция, 2003. — 640 c.
ISBN 5-7502-0223-2
Скачать (прямая ссылка): mcrsftado2003.pdf
Предыдущая << 1 .. 161 162 163 164 165 166 < 167 > 168 169 170 171 172 173 .. 260 >> Следующая

мастером, можно, но при изменении конфигурации объекта DataAdapter все эти изменения будут И все же, несмотря на свое несовершенство, мастер Data
Adapter Configuration Wizard — мощная и полезная утилита.
Прочие проблемы обновления
Вы уже изучили основные принципы обновления содержимого БД с использованием отложенных изменений, хранящихся в объекте DataSet. Если вы генерируете собственную логику обновления (в форме запросов INSERT, UPDATE и DELETE или вызовов хранимых вам необходимо знать чем просто
гчаювы.
ГЛАВА 10 Передача обновлений в базу данных 383
IbiijHiMcp. как управлять параллелизмом, чтобы случайно не перезаписать изменения, сделанные другим пользователем? Как обрабатывать значения NULL при управлении параллелизмом? Как передавать обновления в транзакции? Какую роль играет набор ТаЫеМар/мщБобъекта DataAdapter при передаче обновлений?
Подробнее о том, как ':су:..о^сте:;-:ть это — в последующих разделах,
Способы оптимистичного управления параллелизмом
При создании многопользовательского приложения для работы с БД. передающего обновления с применением оптимистичного управления параллелизмом, важно реализовать в обновляющих запросах оптимистичный контроль параллелизма. Скажем, два пользователя вашего приложение запросили одну и ту же запись данных и пытаются обновить ее. Что произойдет? Это зависит от структуры обновляющих запросов.
Предлагается четыре основных способа оптимистичного управления параллелизмом.
И с пол ь зование только полей первичного ключа
SQL-запросы UPDATE и DELETE можно жиюч;пь только поля первичного ключа; про этом возникает ситуация ш ккждлсо пришедший последним». Обе попытки
обновления завершатся успешно. Понятно, что БД не способна поддерживать оба
набора обновлений. Должен остаться лишь один. Изменения, сделанные первым будут переопределены изменениями, внесенными последним пользователем.
Вот кратко последовательность действий при возникновении подобной ситуации:
• пользователь А выбирает запись;
• пользователь Б выбирает запись;
• пользователь Б изменяет запись и успешно передает изменения;
• пользователь А изменяет запись и успешно передает изменения, перезаписы-
внесенные пользователем Б.
Пользователь А даже не что в период времени между выполнением ис-
ходного запроса и передачей обновлений в БД соответствующая запись БД была
изменена другим пользователем.
Если ситуация «побеждает пришедший последним» - именно i о. что вам нужно, данный способ управления параллелизмом подойдет вам. Однако когда требуется исключить возможность непреднамеренной перезаписи чужих изменений другими пользователями, этот способ неприемлем.
В отличие от мастера DataAdapter Configuration Wizard, объект CommandBuikler не предоставляет такого варианта оптимистичного управления параллелизмом. На вкладке Advanced Options диалогового окна мастера снимите флажок ! se Optimistic Concurrency.
Использование всех полей в разделе WHERE
Что, если вариант «побеждает пришедший последним» вам не подходит? Например, требуется исключить возможность перезаписи А изменений.
384 Часть Ill Автономная работа с данными: объект DataSet модели ADO net
внесенных в БД другими пользователями в период между выполнением пользователем А оригинального запроса и передачей им обновлений в БД.
По умолчанию объект СоттапаВиШегж мастер Data Adapter Configuration Wizard иклднию! в раздел WHERE все поля. Такая логика исключает перезапись изменений, сделанных другими пользователями в интервал времени между тем моментом, когда ваш код выбрал за~К"?ь. и тем, когда он попытался передать отложенные изменения этой записи в БД.
Рассмотрим пример. Скажем, пользователи А и Б выбрали одну и ту же запись о клиенте. Пользователь Б изменил значение поля О шипМзшс и передал изменение в БД. При на основе запросов приложение включает в раздел WHERE все поля, и поэтому запрос UPDATE выглядит следующим образом:
UPDATE Customers
SET CustomerlO = 'ABCDE', CompanyName = 'Original Company Name1,
ContactName = ' New Contact ', Phone = '800-555-1212' WHERE CustomerlO = 'ABCDE' AND
CompanyName = 'Original Company Name' AND
ContactName = 'Original Contact' AND
Phone = '800-555-1212'
Тем временем пользователь А изменил значение поля CompanyName той же записи. Поскольку пользователь А выбрал запись до того, как пользователь Б передал измененное значение поля ContactName в БД. запрос UPDATE пользователя А будет выглядеть так;
UPDATE Customers
SET CustomerlD = 'ABCDE', CompanyName = 'New Company Name',
ContactName = 'Original Contact', Phone = '800-555-1212' WHERE CustomerlD = 'ABCDE' AND
CompanyName = 'Original Company Name' AND ContactName = 'Original Contact' AND Phone = '800-555-1212'
Значение поля ContactName этой записи в БД изменилось, и поэтому ни одна запись таблицы не удовлетворяет критериям раздела WHERE. Следовательно, БД не изменит запись о клиенте. Объект DataAdapteг обращается к БД, чтобы узнать число измененных запросом записей, обнаруживает, что нужная запись не откорректирована, и соответствующим образом помечает объект Datidiuir. Подробнее о выявлении и разрешении таких конфликтов — в главе I
Предыдущая << 1 .. 161 162 163 164 165 166 < 167 > 168 169 170 171 172 173 .. 260 >> Следующая
Реклама
Авторские права © 2009 AdsNet. Все права защищены.
Rambler's Top100