Веб-фронтенд разрабатывает для параллельной модификации
Отредактированный для комментирования относительно комментария:
Вы прокомментировали
В отладчике, значение = "Ошибка 2015" и тип = "Вариант/Ошибка"
, Эта ошибка означает, что Ваш Value во время выполнения #VALUE!. Можно обработать это событие правильно первым использованием следующего условного выражения:
If Not IsError(Cells(i, 83).Value) Then
...
4 ответа
Как насчет бронирования по времени? Эта модель используется во многих системах онлайн-бронирования.
Пример, основанный на тривиальном случае с одной таблицей (я надеюсь, что расширение на большее количество таблиц должно быть очевидным) Добавьте столбец в таблицу с именем RESERVATION_TIME. Все записи изначально заполняются с резервированием «много лет назад».
Используйте это в сочетании с оптимистической блокировкой. В момент перехода в режим редактирования вы
Зарезервируете запись, которую хотите
UPDATE RESERVATION_TIME до NOW, где KEY = id и RESERVATION_TIME более 30 минут назад
Это будет работать, только если еще никто не сделал этого установить обновление на последнее время. Идея состоит в том, что мы даже не позволяем заполнять экран редактирования, если какой-то другой пользователь уже работает. Но мы устанавливаем, что это резервирование истекает через 30 минут (или что-то еще), чтобы ничего не было «заблокировано» навсегда. Но обратите внимание, что мы не (с точки зрения базы данных) удерживаем пессимистическую блокировку.
Теперь извлеките данные (возможно, в той же транзакции, что и резервирование)
при обратной записи проверьте оптимистический предикат и очистите резервирование до давным-давно.
Теперь это является посредником между двумя пользователями любых приложений, которые поддерживают систему бронирования. Оптимистическая блокировка является посредником между всеми оптимистично настроенными пользователями системы, поэтому пользователь все еще может быть раздражен, но если предположить, что внеполосные обновления редки, вы должны получить приемлемое удобство использования.
Некоторые другие идеи:
- ] Побеждает последнее сохранение - для некоторых данных нет смысла блокировать. Вы собирались позволить пользователю Биллу изменить Алису » s работают в любом случае, и наоборот, поэтому позвольте любому из них выиграть.
- Обнаружение конфликта и слияние. Как система контроля версий CVS. Используйте оптимистичную схему и в случае конфликта представьте промежуточное обновление и предлагаемое обновление и попросите пользователя разрешить конфликт.
Мы реализуем механизм «первая запись-выигрыш» в аналогичных ситуациях (или оптимистическая блокировка)
НАЗАД:
Создание поля временной метки в базе данных (оно автоматически обновляется в MSSQL на INSERT и UPDATE)
Когда вы загружаете объекты для редактирования, включая свойство отметки времени, разрешите сохранение в ваших хранимых процедурах только в том случае, если отметка времени такая же, иначе выдает ошибку, обработайте это в своем приложении, указав, что запись была изменена и дайте им возможность перезагрузить страницу. Это хорошо работает в веб-средах и в автономных средах.
FRONT END
Странице необходимо опросить базу данных (с помощью ajax), чтобы обнаружить изменение. Если есть запрос на изменение, пользователь указывает, что запись была изменена, и возможность перезагрузки / слияния.
Я согласен с вами, что оптимистическая блокировка не так удобна для пользователя.
Что касается пессимистической блокировки, я думаю, вы можете решить эту проблему:
Чтобы разблокировать блокировку чаще , вы можете использовать задержку для блокировки в своей базе данных. По истечении этого срока другой пользователь может снять блокировку. Об этом будет уведомлен первый пользователь. Это должно быть ясно с самого начала.
Вы также можете использовать периодическое автоматическое обновление на странице блокировки. При каждом запросе (ajax) вы запоминаете время. Следовательно, если на сервере блокировка старше частоты обновления, это означает, что пользователя больше нет на этой странице. Таким образом, даже если сеанс не истек, вы можете очистить блокировку.
Оптимистическую блокировку можно сделать удобной для пользователя, извлекая измененные записи и показывая сравнения с данными. они отправили.
Вы могли бы пойти еще дальше и реализовать интерфейс, подобный TortoiseSVN, для редактирования конфликтов (если они есть).
Это может потребовать некоторых усилий пользовательского интерфейса, но в результате получится хороший о разрешении одновременного редактирования.