Обработка конфликтов редактирования

 

Многопользовательские БД — пример неограниченной свободы. Обычно программа Access не накладывает никаких ограничений на многопользовательские корректировки. Если повезет, пользователи будут вносить изменения в определенном порядке, один за другим. Но рано или поздно, изменения наложатся друг на друга и, возможно, с серьезными последствиями.

Далее приведен пример, показывающий, к чему приводит наложение изменений.

1.          Вы открываете запрос, отображающий все товары в БД Boutique Fudge.

2.          Ищите запись — самый хорошо продаваемый чизкейк с названием Chocolate Abyss, нуждающийся в изменении. Для того чтобы начать редактирование, вы щелкаете кнопкой мыши в поле Description.

3.          В это же время Билл Эванс (Bill Evans) в отделе продаж запускает форму, которая тоже использует таблицу Products. Он добирается до той же самой записи и, догадываясь о возможности получений большей прибыли, начинает изменять цену. Теперь два пользователя работают одновременно с одной записью. Что произойдет дальше, зависит от того, кто первым зафиксирует свои изменения.

4.          Допустим, что Билл выполнил свою работу первым. В мгновение ока он повысил цену и перешел к другой записи.

5.          Вернемся к вашему компьютеру, вы закончили исправление поля Description и переходите к другой записи. Обычно в этот момент программа Access фиксирует ваши изменения, сохраняя их в серверной БД. Но в данном случае Access замечает противоречие — а именно, версия записи, с которой вы работаете, не совпадает с текущей версией записи в БД.

6.          Access предупреждает вас о проблеме и предоставляет три возможных варианта ее исправления (рис. 18.10).

Рис. 18.10. Между временем начала вашего редактирования и моментом внесения его в БД кто-то еще внес изменения. Программа Access разрешает выбрать вариант обработки возникшей конфликтной ситуации

 

Разрешить конфликтную ситуацию можно тремя способами.

Вариант Сохранить запись (Save Record) — самый легкий и самый опрометчивый. Если выбрать его, программа Access запишет вашу версию записи поверх имеющейся в БД. Проблема состоит в том, что этот вариант аннулирует изменения, сделанные другим пользователем. В предыдущем примере в БД будет сохранено новое описание товара, но потеряется изменение цены, поскольку Access запишет ее прежнее устаревшее значение.

Вариант Отменить изменения (Drop Changes) отменяет ваше редактирование. Access обновит запись и отобразит самую свежую информацию, а затем вы можете попытаться внести ваше изменение снова. Этот вариант заслуживает внимания, если вы легко сможете повторить редактирование, но его нельзя считать хорошим выбором, если вы только что закончили подробное обновление большого текстового поля.

Вариант Копировать в буфер (Copy to Clipboard), как и предыдущий вариант, отменяет ваше редактирование. Однако значения, которые вы изменили, копируются в буфер, что облегчит повторное их применение, как показано на рис. 18.11.

Рис. 18.11. Если результаты последнего редактирования скопированы в буфер, понадобятся два шага для повторного их внесения. Сначала вставьте их в другую программу (например, показанную здесь программу Word). Затем выделите данные, которые хотите использовать, и снова скопируйте их в буфер с помощью комбинации клавиш <Ctrl>+<C>. И, наконец, перейдите в окно программы Access к полю, которое хотите изменить, и вставьте новое значение, нажав комбинацию клавиш <Ctrl>+<V>

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

 

Примечание

Любители Access часто говорят о том, что им хотелось бы иметь возможность объединять изменения, т. е. обновлять только те поля, которые менялись. В предыдущем примере такая возможность позволила бы применить новое описание поля без повреждения изменения цены, сделанного предыдущим пользователем, поскольку оба обновления воздействуют на разные поля. Но программа Access не предоставляет такого варианта. Одна из причин — отсутствие возможности проверить непротиворечивость обоих изменений. Нет ничего хуже записи, противоречащей самой себе.

 

 

Разделение таблиц для более безопасных корректировок

 

Один из способов снижения числа накладывающихся корректировок — разделение таблицы на более мелкие фрагменты. Основная идея — взять единую таблицу с большим числом полей и разделить ее на две меньшие таблицы, каждая из которых включает только некоторое число этих полей. Например, можно взять таблицу Customers (клиенты) и разделить на таблицу CustomerAddress (адрес клиента) и таблицу CustomerFinancial (финансовая информация клиента). Каждая запись таблицы CustomerAddress связана с единственной записью таблицы CustomerFinancial с помощью отношения "один-к-одному". Для получения всей информации о клиенте вам понадобятся обе записи.

Лучше всего делить таблицу, когда вы выясните, что типичное редактирование включает поля только из одной таблицы. Возможно, вы знаете, что отдел по обслуживанию клиентов часто обновляет адресные данные, а финансовый отдел работает с финансовыми сведениями, в этом случае разделение таблицы — прекрасная идея. Отдел по обслуживанию клиентов будет использовать таблицу CustomerAddress почти монопольно, а финансовый отдел будет работать с таблицей CustomerFinancial. Вероятность наложения корректировок резко снижается, поскольку обработка делится между двумя таблицами.

 

 

Вы можете следить за любыми ответами на эту запись через RSS 2.0 ленту. Вы можете оставить ответ, или trackback с вашего собственного сайта.

Оставьте отзыв

XHTML: Вы можете использовать следующие теги: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

 
Rambler's Top100