Настройки блокировки Access

Лучший способ обработки возникающих при работе в многопользовательской среде ошибок состоит в их предотвращении. В Access имеется несколько свойств, которые можно использовать для снижения ча­стоты возникновения конфликтов доступа. Соответствующие параметры можно отыскать во вкладке Advanced диалогового окна Options. Однако сами по себе они не осуществляют обработку подобных ошибок.

• Number of Update Retries (Число повторов обновления) - управляет количеством попыток, кото­рые Access предпринимает при сохранении или обновлении заблокированной записи. Допустимые значения находятся в интервале 0-10.

• ODBC Refresh Interval (Период обновления ODBC (с)) - период обновления в секундах при ис­пользовании базы данных ODBC. Допустимые значения находятся в интервале 1-32766.

• Refresh Interval (Период обновления (с)) - период обновления записей в секундах в режиме про­смотра Datasheet (Таблица) или Form (Форма). Допустимые значения находятся в интервале 1-32766.

• Update Retry Interval (Период повтора обновления (мс)) - промежуток времени в миллисекундах, по истечении которого Access предпринимает следующую попытку сохранения измененной записи, которая ранее была блокирована. Допустимые значения находятся в интервале 1-1000.

Конфликт записи

Ошибка Write Conflict (Ошибка конфликта при записи) (см. табл. 4, ошибка 3197) является одной из наиболее неприятных ошибок, возникающих при работе приложения Access в многопользовательской среде. Она возникает в случаях, когда пользователь А открывает запись с оптимистической блокировкой и во время ее редактирования к ней обращается пользователь Б, изменяя и сохраняя ее. Когда пользо­ватель А завершает работу над записью и предпринимает попытку ее сохранения, он получает сообще­ние об ошибке. В предшествующих версиях Access в подобных ситуациях отображалось маловразумительное диалоговое окно, в котором предлагалось перезаписать изменения другого пользователя (при этом не со­общалось, какие именно), отказаться от только что внесенных изменений (что никогда не пользовалось популярностью) либо скопировать данные в буфер обмена (и что делать дальше?).

В настоящее время способ внутренней обработки ошибок подвергся изменениям. В Access 2000 конф­ликт записи приводит к игнорированию внесенных пользователем А изменений. Хотя подобная мера кажется излишне суровой, она наилучшим образом соответствует ситуации, когда большинство многополь­зовательских приложений Access поспешно создаются людьми, которые не всегда достаточно хорошо разбираются в вопросах многопользовательского применения. По крайней мере, такая обработка конфликта записи является решительной и окончательной, а пользователям не придется искать ответ на вопрос, над которым они никогда не задумывались. Если приложение должно обрабатывать конфликт записи иным способом, необходимо создать пользовательскую процедуру обработки ошибки.

Блокированная запись

Когда в ходе обычного использования приложения пользователь А пытается изменить запись, редак­тируемую пользователем Б, первый из них получит сообщение об ошибке 3260 (Запись блокирована - см. табл. 4). Как правило, подпрограмма обработки ошибок предпринимает заданное число попыток со­хранения записи пользователя А перед тем, как предложить ему подтвердить необходимость дальнейших попыток либо отказаться от изменения записи. Если примененная пользователем Б блокировка является пессимистической, она снимается сразу после обновления записи в базе данных. Как правило, этот пе­риод времени очень короток.

Транзакции

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

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