Таблица 5 Сочетания свойств NativeError и Number объекта Connection. Errors для идентификации типа блокировки
| Пользователь | Свойство | Значение | Тип блокировки |
| Данный пользователь | Connection.Errors(0).NativeError | -533791822 | Пессимистическая |
| Данный пользователь | Connection.Errors(O).Number | -105514571 | Оптимистическая |
| Другой пользователь | Connection.Errors(O).NativeEr | -2147467259 | Пессимистическая |
| Другой пользователь | Connection.Errors(O).Number | -2147217887 | Оптимистическая |
На данном этапе смысл этих значений не совсем очевиден, разве что их можно использовать при выборе момента для еще одной попытки обновления данных. Однако реальную ситуацию, когда они могут понадобиться, предвидеть трудно. Пока будем считать их применение делом будущего.
Использование блокировки страниц
Как уже говорилось, в течение длительного периода в Access не существовало возможности непосредственной блокировки отдельных записей, предоставлялась лишь блокировка целых страниц. Чтобы использовать преимущества более высокой производительности при задействовании страничной блокировки, необходимо отключить установленный по умолчанию параметр блокировки на уровне строк. Для этого следует выполнить команды меню Tools / Options [ Advanced и отключить флажок Open databases with row-level locking (Блокировка записей при открытии базы данных).
Обработка ошибок блокировки при работе в многопользовательской среде
Любая многопользовательская система должна предвидеть ошибки блокировки. Различные системы обрабатывают возникающие в определенных ситуациях ошибки по-разному. Кроме того, в случаях возникновения ошибок блокировки различные системы предоставляют разработчикам и пользователям неодинаковую информацию. В данном разделе рассматриваются некоторые настройки блокировки и связанные с нею ошибки, с которыми чаще всего приходится сталкиваться при разработке приложений в Access 2000. Здесь также поясняются некоторые технологии предотвращения и обработки этих ошибок.
Настройки блокировки 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). Как правило, подпрограмма обработки ошибок предпринимает заданное число попыток сохранения записи пользователя А перед тем, как предложить ему подтвердить необходимость дальнейших попыток либо отказаться от изменения записи. Если примененная пользователем Б блокировка является пессимистической, она снимается сразу после обновления записи в базе данных. Как правило, этот период времени очень короток.
Транзакции
Транзакция объединяет в себе отдельные либо элементарные операции и выполняет их как единый процесс. Весь набор команд транзакции завершается успешно (изменения сохраняются) либо весь отклоняется (происходит откат). В случае неудачи транзакции база данных возвращается в исходное состояние (выполняется операция отката), в котором она была до начала выполнения транзакции. Это гарантирует, например, что при внесении в товарный чек данных о товаре они одновременно удаляются из инвентарной описи. Когда один счет увеличивается, тогда другой уменьшается, а при записи изменений соответствующая информация вносится в контрольную таблицу. В весьма динамичной среде многопользовательского приложения выполняющий подобные обновления и дополнения пользователь в ходе выполнения отдельных операций подобного процесса, скорее всего, столкнется с ошибками блокировки записей, оставляя незавершенными балансовые счета, завышенные сведения о количестве товаров в описи либо внесенные, но несохраненные изменения. Короче говоря, транзакции помогают поддерживать целостность данных в условиях частых блокировок нескольких записей. В многопользовательском приложении транзакции следует использовать во всех возможных случаях.
Однакб транзакции имеют не одни лишь преимущества. Чтобы обеспечить выполнение всех изменений транзакция собирает информацию о блокировках. Транзакции устанавливают все требуемые приложением блокировки и не снимают их до завершения всего процесса, при этом ошибки возникать не должны. Поскольку существует вероятность установки большого количества блокировок и время их действия оказывается более длительным, чем если бы они устанавливались только частью всего процесса, возможность одновременного доступа многих пользователей при обращении приложения к данным в действительности снижается. Однако в любом случае база данных, допускающая использование большим количеством пользователей, но не обеспечивающая целостность данных, ценится невысоко. Поэтому компромисс между целостностью данных и возможностью доступа со стороны многих пользователей является оправданным.