http://stackoverflow.com/questions/1826241/how-do-i-prevent-an-error-2101-in-access-when-i-have-a-button-to-save-a-record-o


Как же всё таки обойти эту проблему элегантно?

Парень в статье советует решение, но оно не подходит. У него слишком просто всё.
В моём случает в событии beforeupdate я блокирую некоторые таблицы в базе, делаю после этого проверки.

Скажем так, я в событии формы form_beforeupdate делаю разные проверки, на основе которых принимается решение не сохранять запись. Делаю cancel = true и после это на строчке me.dirty = false вылетает ошибка.

И вот сижу и думаю, как-же решить эту проблему. Неужели придётся костыли какие-то делать?

Вопрос: как красиво, по умному, обработать сообщение об ошибке после me.dirty = false, (после cancel = true в событии private sub form_beforeupdate(cancel as integer) ?

Дело в том, что в событии Form_BeforeUpdate(Cancel As Integer) в моём случае нельзя использовать Me.Undo

Нельзя сбрасывать данные на экране просто так.

Всё должно оставаться на своих местах, но программа должна сказать, что не может сохранить запись.
Она это и говорит.

Но поскольку событие Form_BeforeUpdate инициируется через Me.Dirty = False,
то понятно, что дальше вылетает ещё одно предупреждение 2101, что команда Me.Dirty = False не смогла отработать.

__Michelle,

Спасибо за обстоятельный подход) Это уже интересно.

Логика в Ваших словах есть! Только надо покрутить эту связку dirty и beforeUpdate
Есть ведь и закрытие формы по крестику. Там ведь наверное автоматически работает dirty

Посмотрю в общем.


в beforeUpdate блокирую вспомогательные таблицы. Чтобы по сети не меняли данные. Потом делаю разные проверки.

Удобно с beforeUpdate . Знаю что именно в этом месте, железно, блокирую таблицы и что никто не зелезет в процесс, пока

afterUpdate не снимет эти блокировки.

В afterUpdate снимаю блокировки с таблиц. Вроде как так удобно получается при работе в сети.

Как вообще сделать? Источник данных для формы - редактируемый. Перед записью в базу данные надо проверить.
Для этого использую связку beforeUpdate afterUpdate

В момент записи, остальные алгоритмы на других компах должны подождать какое-то время.

Access ведь автоматически сохраняет данных.

Получается, что beforeUpdate формы, это единственное место, где я могу запустить проверки, устанавливать разные блокировки ?

Я проверил. Открыл форму. Изменил данные. Нажал на крестик, чтобы закрыть окно.

Попал в событие beforeUpdate

После проверок в этом событии, предположим, надо сделать cancel = true


Допустим сделаю.

Тогда в другом случае для Me.dirty = false это вызовет ошибку.

Ребята как бы Вы сделали?

На экране есть форма. Источник данных для формы: запрос или таблица (динамический).

Перед сохранением записи в базу данных нужно сделать несколько проверок.
С учётом того, что по сети с базой работают другие пользователи.
Если проверка не проходит - не сохранять данные.

При проверке некоторые ресурсы должны быть заблокированы на микросекунды.
То есть: проверка и сохранение с каком то смысле должны делаться монопольно доли секунды.

Я не придумал ничего лучшего как блокировать специальную таблицу в событии beforeUpdate формы.
Делать в этом событии проверки, отменять если что это событие.

Если проверки проходят успешно. то дальше в событии afterUpdate ajhvs снимать блокировку.

Такой подход работает. Он гарантирует, что пока код выполняется, другие не могут внести изменения, поскольку натыкаются на заблокированную вспомогательную таблицу.

Случайно выяснил проблему с Me.Dirty
Это не такая большая проблема. Пока я так думаю) Может ошибаюсь.
Но решил исследовать ситуацию.

Может я не совсем правильно, что-то делаю. Подскажите плиз всем, чем можете)

sdku,

авторНе понимаю,в силу моей тупости, ЧТО дает насильственное присваивание этому свойству значения

Ну это просто. Так мы принудительно сохраняем запись в базе.
Например Вы вносите данные. Решили чай попить. Форму закрывать не хочется.

Me.Dirty = False помогает)

sdku,

авторВсегда думал что в программировании элегантность и простота синонимы

Да! :)

vmag,

авторЗабей... не нужно ничего блокировать...

Пожалуй это самый лучший совет:)

автор- Напиши отдельную функцию проверки, которая возвращает (например) 0 если всё нормально и 1 если всё плохо

Так тоже делаю.

автор- Сделай отвязанную форму, корректирующую БД сохраненными запросами или DAO.

Так тоже делаю. В этой форме нажимаю кнопку Cохранить, каюсь, дальше блокирую вспомогательные таблицы, после всех проверок, пишу в базу, снимаю блокировки, и уже после этого выдаю сообщения.

авторЧто там хоть у тебя за база такая, что за доли секунды может щемиться в одну запись куча юзеров ?
Может это всё надумано ?

Просто перестраховываюсь, чтобы всё работало железобетонно) База правда серьёзная, бизнес-логика накрученная,
учитываю все мыслимые и немыслимые ситуации,
особенно при сетевой работе.

Раньше проще делал, а по мере накопления опыта, код сам по себе начинает усложняться)

up)