Учебная работа. Реферат: База данных Access. Особенности работы в многопользовательском режиме

Учебная работа. Реферат: База данных Access. Особенности работы в многопользовательском режиме

база данных
Access. Индивидуальности работы в многопользовательском режиме

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

Конфликты доступа

Принципиально держать в голове, что работа с базой данных в многопользовательской среде может вызывать пробле­мы, связанные с блокировкой данных и конфликтами доступа к ним. Угнетение сообщений о ошиб­ках, недостающее внимание к схожим вопросцам или надежда на подходящее стечение событий не решает делему. Невзирая на кажущуюся сложность работы в многопользовательской среде, осознать механизм деяния блокировки данных и метод обслуживания механизмом Jet нескольких юзеров довольно просто. Пренебрежение схожими вопросцами, как правило, приводит к появлению бо­лее сложных заморочек, затрагивающих юзеров, клиентов и влияющих на репутацию разраба. Если для приложения не предвидено действенное решение вопросцев работы в многопользовательской среде, при работе с ним безизбежно будут возникать последующие трудности:

• Новейшие записи не сохраняются. Опосля ввода инфы юзер обнаруживает, что в базе данных она не возникла. Если схожая ошибка не повторяется, это гласит не о отсутствии трудности, а о ненадежности приложения.

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

• Юзеры получают безрассудные сообщения о невозможности обеспечить доступ к данным. Хотя последствия подобного рода проблем не настолько драматичны, как в прошлых вариантах, для юзера будет мощным разочарованием необходимость работы с приложением, которое не может совладать даже с таковой легкой неувязкой.

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

Конфигурация

Для обслуживания нескольких юзеров приложение Access нужно на файловом уровне кон­фигурировать по-разному. Любой метод имеет свои достоинства и недочеты, некие из их пе­речисляются ниже.

• Сетевое размещение. В данной конфигурации единый MDB-файл размещается на сетевом серве­ре, и юзеры получают доступ к базе данных при воззвании к серверу. Данные и выполня­емые модули могут содержаться в едином MDB-файле или располагаться на файловом сервере в виде нескольких отдельных файлов. Преимуществом данной конфигурации является простота поддержки, так как по мере необходимости в обновлении нуждается только выполняемый файл. Но, так как все формы, отчеты, модули, запросы, ЕХЕ-файлы Access, также все библиотеки DLL и т.п. должны передаваться по сети на рабочую станцию, сетевой трафик необоснованно растет, а производительность существенно понижается. возможно, в схожих конфигурациях следует исполь­зовать связанные формы. Дальше рассматриваются трудности связывания форм с данными и возни­кающие при всем этом конфликты доступа.

• Разбитая база данных с размещенными в сети данными. Таковая конфигурация по традиции на­зывается конфигурацией удаленной базы данных (отметим, что клиент-сервер, механизм баз данных Access на пользовательском ПК получает, обрабатывает, перекрывает и снимает блокировку с данных, находя­щихся в MDB-файле на сетевом сервере. Работа в таковой конфигурации зависит от устройств баз данных сразу работающих юзеров, также от способностей файлового сервера, касающихся поддержания сетевого графика. До реального времени при размещении приложений баз данных Access предпочтение отдают конкретно этому способу. Его преимуществом является высо­кая производительность и маневренность при корректном использовании. Так как при размеще­нии данных в сети по каналам связи передаются лишь они, сетевой трафик существенно понижается. Главный недочет данной конфигурации состоит в том, что на любом клиентском ПК нужно устанавливать Access и выполняемый MDE- (скомпилированный вариант базы данных MDB) или MDB-файл, что осложняет поддержку приложения. Тем не наименее, есть спосо­бы решения схожей трудности.

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

• Конфигурация клиент-сервер. В Access 2000 возникла новенькая возможность сотворения клиент-сервер­ных приложений на базе проекта Microsoft Access. В таковой конфигурации удаленными являются как данные, так и механизм баз данных. Если данными управляет SQL Server, Oracle либо какой-нибудь другой баз данных, расположенный на центральном компе, он также решает вопросцы блокировки и трудности работы в многопользовательской среде. Это не значит, что разраб избавлен от необходимости решения всех связанных с ними задач, просто ему приходится иметь дело с другими наборами параметров, способностей и правил. Главными преимуществами таковой конфигу­рации являются высочайшая производительность, стабильность, возможность обслуживания огромного количества юзеров и выполнения огромного количества задач. Больший недочет данной конфи­гурации состоит в высочайшей цены и значимой трудности.

В данной главе рассматриваются вопросцы, которые являются общими для сетевых конфигураций: схе­мы разбитой базы данных и реализации архитектуры клиент-сервер. О репликации рассказывается в главе 22.

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

Access и методы блокировки в Jet

Механизм Jet имеет схему блокировки, которая дозволяет отлично обслуживать несколько пользо­вателей. При использовании Jet с Access, а не с VB либо любым другим инвентарем разработки нужно учесть, что некие деяния производятся по дефлоту. Данный раздел посвящен исследованию этих вопросцев.

Главные сведения о блокировке

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

В диалоговом окне Options (характеристики), отображающемся при выполнении установок меню Tools Options (Сервис / характеристики), во вкладке Advanced (Остальные) имеется параметр Default open mode (Режим откры­тия, определенный по дефлоту). тут можно найти режим открытия базы данных, т.е. обязана ли она раскрываться для монопольного доступа (лишь для 1-го юзера на весь сеанс работы) либо для общего доступа.

Если избран режим Exclusive (монопольный доступ), базу данных имеет Право открывать лишь один юзер. В этом случае Access изменяет заголовок LDB-файла, тем заблокируя его (подробнее о этом см. в разделе «LDB-файл«) и запрещая доступ к данным для всех остальных юзеров. Очевид­но, для многопользовательского приложения таковая настройка употребляться не обязана. Но такие процедуры, как сжатие и восстановление, следует делать над базой данных, открытой для монополь­ного доступа.

Режим Shared (Общий доступ) дозволяет открывать базу данных нескольким юзерам одновре­менно. При всем этом Access в момент открытия базы данных вносит информацию о подключившихся к ней юзерах в LDB-файл и использует механизм блокировки и освобождения страничек и строк.

Эти и остальные характеристики можно задавать в командной строке во время пуска приложения Access. Некие из их перечислены в табл. 1.

Таблица 1 характеристики командной строчки при запуске Access

Параметр

Описание

/Excl

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

/Ro

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

Отсутствует

Режим, определенный по дефлоту. Отсутствие параметра /Excl либо /Ro дозволяет открывать базу данных в режиме общего доступа или в согласовании с определенным для нее режимом.

СОВЕТ

По мере необходимости совместного использования принципиально предупредить открытие базы данных в монопольном режиме. Этого можно достигнуть, отключив параметр OpenExclusive при определении опций для рабочих групп и задании характеристик защиты данных в приложении. Наиболее тщательно эта тема рассматривается в иной статье.

Задавая характеристики базы данных, разраб может выбирать режим блокировки записи по умолча­нию: блокировку на уровне строчки или на уровне странички.

Сопоставление блокировки на уровне странички с блокировкой на уровне строчки

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

В Access 2000 механизм баз данных Jet 4.0 дозволяет разрабам выбирать способ блокировки по дефлоту: на уровне строчки или на уровне странички. сейчас юзер может перекрыть лишь редактируемую запись, а не все записи на страничке. Так как отдельная запись может блокироваться только на куцее время (к примеру, при выполнении операторов SQL Delete, Update либо Insert), возможность конфликта 2-ух юзеров во время ее редактирования ниже, чем при одновременной блокировке нескольких записей в схеме страничной блокировки. Ранее возможность конфликта множилась на число записей на страничке, определение которого было затруднено. количество записей на страничке данных зависело от размера записей и от времени их ввода, потому предугадать возможность конфликта было проблемно.

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

С иной стороны, если к базе данных должен обеспечиваться доступ почти всех юзеров, а одно­временное редактирование каждым юзером наиболее одной записи неприемлимо, может быть примене­ние блокировки на уровне строчки. Это тем наиболее правильно при активном редактировании базы данных. Ворачиваясь например банковской системы, необходимо подчеркнуть, что записи базы данных с информацией о депозитах и изъятиях со счетов клиентов должны быть вседоступны. При редактировании записи ее следует перекрыть, в неприятном случае существует риск, что внесенные юзером конфигурации бу­дут перезаписаны конкурирующим юзером. Наиболее того, редактирование одной записи не обязано препятствовать редактированию примыкающей записи остальным юзером. Блокировка на уровне строчки может применяться в ситуациях, когда запись обязана оставаться открытой некое время, в течение которого ее не могут редактировать остальные юзеры. Примером может служить просмотр инфы о кли­енте для подведения баланса или оценки его кредитоспособности. До окончания просмотра и принятия решения изменять запись не нужно. Если запись остается открытой в течение нескольких минут, лучше избегать блокировки нескольких остальных записей на время ее редактирования. Обычно, следует избегать даже одной записи в течение довольно долгого периода времени, если лишь это не является полностью нужным.

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

LDB-файл

Файл блокировки — это особый временный файл, создаваемый при открытии базы данных Access. Он содержит информацию о используемых в базе данных блокировках, также о ее юзерах. При закрытии базы данных файл удаляется. Его имя совпадает с именованием соответственной базы данных, но он имеет расширение LDB. Этот файл постоянно размещается в том же каталоге, что и база данных.

Сопоставление жизнеутверждающей, пессимистической блокировок и блокировки на уровне строчки

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

Жизнеутверждающая блокировка

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

«The Microsoft Jet database engine stopped the process because you and another User are attempting to change the same data at the same time.»

(«Механизм баз данных MicrosoftJet приостановил процесс, так как вы и иной юзер сразу предприняли попытку доступа к этим же данным».)

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

Пессимистическая блокировка

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

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

Блокировка на уровне строчки

Главным преимуществом блокировки на уровне строчки является расширение доступа к базе данных для почти всех юзеров. При блокировке единственной редактируемой записи почти всем юзерам пре­доставляется доступ к большему размеру данных без появления конфликтов блокировки либо доступа к записям. Внедрение блокировки на уровне строчки также дозволяет разрабам расширить гра­ницы использования пессимистической блокировки. Таковым образом, юзерам предоставляются бо­лее знакомые и тривиальные условия работы, в процессе которой они делают легкие операции открытия записи, ее редактирования и сохранения конфигураций. В предыдущих версиях Access пессимистическая блокировка не могла получить широкого распространения, так как страничный метод блокировки ог­раничивал количество сразу работающих юзеров, которые должны были мириться с воз­можностью блокировки внесенных ими конфигураций иными юзерами. При всем этом разрабам приходилось создавать схемы реализации обычных для юзеров критерий работы (расширяющиеся записи, временные таблицы и т.п.). Блокировка на уровне строчки является основным достижением в Jet 4.0. Она обязана отыскать csoe применение в более фаворитных и надежных приложениях.

Свойство RecordLocks и связанные интерфейсные элементы

При открытии в Access связанной формы либо набора записей имеется возможность наложения бло­кировки на соответственный набор записей. естественно, эти характеристики можно употреблять лишь при ра­боте с Jet, тогда как при использовании конфигурации приложения Access клиент-сервер предполагается установка режима No Locks (отсутствует).

Существует три режима блокировки:

• No Locks (отсутствует) — эквивалентен жизнеутверждающей блокировке,

• Edited Records (изменяемой записи) — эквивалентен пессимистической блокировке,

• All Records (всех записей) — блокировка всех записей набора. В многопользовательских приложениях этот режим следует употреблять с осторожностью.

СОВЕТ

Связывание пользовательского интерфейса с данными является обычным методом предоставления юзерам доступа к данным, но при всем этом пропадает контроль над данными. В связанной с пессимистически блокированной за­писью форме юзер увидит в панели выбора записи знак «перечеркнутое О», но информация о том, кто заблокировал запись, отсутствует. Если панель выбора записи не отображается, юзер услышит звуковой сигнал.

Способы блокировки в Jet

Блокировка — обыденное и нужное явление в базе данных. Чтоб убедиться в правильности типа и установить длительность блокировки, нужно при ее возникновении иметь возможность получать о ней информацию. Данный раздел будет полезен при анализе особенностей блокировки в приложении, который проводится для проверки соответствия способностей приложения цели, с которой оно создава­лось.

Определение состояния блокировки

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

В ADO существует свойство набора записей LockType,
содержащее информацию о используемом к записям типе блокировки. Это свойство доступно для чтения и записи до момента открытия набора за­писей, если набор записей уже открыт, оно доступно лишь для чтения. значения характеристики LockType
для Microsoit.Jet.OLEDB.4.0 приводятся в табл. 2. При использовании остальных поставщиков могут применяться другие константы. Для определения поддерживаемых поставщиком характеристик следует употреблять способ . Supports
с параметрами adUpdate
или adUpdateBatch.

Таблица 2 Константы для характеристики LockType в Jet 4.0 при использовании провайдера Microsoft.Jet.OLEDB.4.0

Константа

Описание

adLockReadOnly

adLockPessimistic

Пессимистическая блокировка при редактировании.

adLockOptimistic

Жизнеутверждающая блокировка при вызове обработчика действия Update.

adLockBatchOptimistic

Жизнеутверждающая блокировка для режима группового обновления.

ПРИМЕЧАНИЕ

Если свойство CursorLocation
имеет adUseClient ,
adLockPessimistic
не поддерживается, но при всем этом ошибка возникать не будет. Jet подставляет в свойство LockType
другое подходящее значения adUseClient
сервер не выслеживает состояние текущей записи, и потому пессимистическая блокировка невозможна.

ПРИМЕЧАНИЕ

ADOR является подмножеством объектной модели ADO и содержит лишь объекты RecordSet и Field.
Он может создаваться специально или передаваться от сервера клиенту. объект ADOR поддерживает единственное значение характеристики LockType — adLockBatchOptimistic.

При разработке, тестировании и поддержке приложения принципиально иметь информацию о состоянии бло­кировки записи. Нужно проверить соответствие всякого процесса обработки данных требованиям, предъявляемым к приложению. Схожая процедура затруднений не вызывает. Следует приостановить выпол­нение программки и проверить LockType
(рис. 1).

РИСУНОК 1
Свойство LockType показывает •остояние блокировки набора wnuceu .

Для индикации режима редактирования набора записей предназначено другое свойство. До вхождения в режим редактирования свойствоEditMode
содержит adEditNone.
Во время редактирования записи оно содержит adEditInProgress.
Опосля удачного обновления записи свойствоEditMode
вновь воспринимает adEditNone.
Другие значения характеристикиEditMode
описываются в табл. 3.

Габлица 3 значения характеристики EditMode набора записей ADO

Константа

Описание

adEditNone

Редактирование не производится.

adEditInProgress

Данные в текущей записи поменялись, но сохранение еще не производилось.

adEditAdd

Данное EditMode
воспринимает опосля вызова способа AddNew
. Оно указывает, что буфер копирования содержит еще не сохраненную новейшую запись.

adEditDelete

Текущая запись была удалена.

EditMode
отражает состояние буфера, применяемого для сотворения и редактирова­ния записей. Оно употребляется, когда при выходе из режима редактирования избран соответственный способ (Update
либоCancelUpdate).

Тестирование блокировок

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

При появлении ошибки провайдер OLEDB Jet выдает определенную информацию о типе блоки­ровки, используемой остальным юзером. В случае конфликта следует проверить свойство подключения:

Connection.Errors( index ). SQLState

для четкого выяснения вида появившейся ошибки. В табл. 4 приводятся некие коды ошибок конф-ликта доступа, возвращаемые при воззвании к свойству .SQLState.

Таблица 4 Коды ошибок блокировки, возвращаемые поставщиком Jet 4.0 OLEDB

Код

Сообщение

3006

Database <name> is exclusively locked. (база данных <имя> употребляется в монопольном режиме.)

3008

The table <name> is already opened by another User, or it’s already open through the user interface and can’t be manipulated programmatically. (база данных <имя> уже открыта остальным юзером, или она открыта средством пользовательского интерфейса, и ее программная обработка запрещена.)

Таблица 4 Коды ошибок блокировки, возвращаемые провайдером Jet 4.0 OLEDB (продолжение)

Код

Сообщение

3009

You tried to lock table <tablename> while opening it, but the table can’t be locked because it’s currently in use. Wait a moment, and then try the operation again. (Предпринята попытка блокировки таблицы <имятаблицы>, но эта операция невозможна, так как в данный момент таблица употребляется. Подождите незначительно, а потом повторите попытку.)

3027

Can’t update; database or object is read-only. (Обновление нереально. база данных либо объект доступен лишь для чтения.)

3046

Couldn’t save; currently locked by another User. (Сохранение нереально. Объект блокирован остальным юзером.)

3158

Couldn’t save record; currently locked by another User. (Сохранение записи нереально. Она блокирована остальным юзером.)

3164

The field can’t be updated because another User or process has locked the corresponding record or table. (Обновление поля нереально, так как соответственная запись либо таблица блокирована остальным юзером или действием.)

3186

Couldn’t save; currently locked by User <name> on machine <name>. (Сохранение нереально. объект блокирован юзером <имя> на компе <имя>.)

3187

Couldn’t read; currently locked by user <name> on machine <name>. (Чтение нереально. объект блокирован юзером <имя> на компе <имя>.)

3188

Couldn’t update; currently locked by another session on this machine. (Обновление нереально. объект блокирован в течение другого сеанса работы на этом компе.)

3189

Table <name> is exclusively locked by User <name> on machine <name>. (Таблица <имя> блокирована в монопольном режиме юзером <имя> на компе <имя>.)

3197

The Microsoft Jet database engine stopped the process because you and another User are attempting to change the same data at the same time. (Механизм баз данных Microsoft Jet приостановил процесс вследствие одновременной пробы 2-ух юзеров поменять одни и те же данные.)

3202

Couldn’t save; currently locked by another User. (Сохранение нереально. Объект блокирован остальным юзером.)

3211

The database engine couldn’t lock table <name> because it’s already in use by another person or process. (Механизм баз данных не выполнил блокировку таблицы <имя>, так как она уже употребляется остальным лицом или действием.)

3212

Couldn’t update; currently locked. (Обновление нереально. объект блокирован.)

3218

Couldn’t update; currently locked by User <name> on machine <name>. (Обновление нереально. объект блокирован юзером <имя> на компе <имя>.)

3260

Table <name> is exclusively locked by user <name> on machine <name>. (Таблица <имя> блокирована в монопольном режиме юзером <имя> на компе <имя>.)

3261

Couldn’t lock table <name>; currently in use by User <name> on machine <name>. (Блокировка таблицы <имя> невозможна. Таблица употребляется юзером <имя> на компе <имя>.)

Массив ошибок также содержит и другую потенциально полезную информацию о ошибке блокиров­ки: данные о блокировке, применяемой остальным юзером. характеристики NativeError и Number
сообща­ют о блокировке, препятствующей выполнению требуемой операции. Сочетания этих параметров и их значения приведены в табл. 5.

Таблица 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 поспешно создаются людьми, которые не постоянно довольно отлично разбираются в вопросцах многопользовательского внедрения. По последней мере, таковая обработка конфликта записи является решительной и конечной, а юзерам не придется находить ответ на вопросец, над которым они никогда не думали. Если приложение обязано обрабатывать конфликт записи другим методом, нужно сделать пользовательскую функцию обработки ошибки.

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

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

Транзакции

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

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

Транзакции являются способами объекта

ADOConnection
.

Способ

Описание

BeginTrans

С вызова данного способа начинается выполнение транзакции.

CommitTrans

Завершает последовательность действий и в случае отсутствия ошибок сохраняет внесенные конфигурации в базе данных.,

RollbackTrans

В случае возникновения ошибки отменяет процесс и возвращает базу данных в состояние, в каком она была до выполнения команды BeginTrans
.

В листинге 1 приводится пример использования транзакции.

Листинг 1 Внедрение транзакции в VBA:

Function TestTrans() As Boolean

Dim conn As ADODB.Connection

Dim rst As ADODB.Recordset

On error resume Err_TestTrans

Set conn = New ADODB.Connection

Conn.BeginTrans

‘выполнениепроцессов, подобныхоператорам SQL, либометодов .Edit,

‘.Update, .AddNew Methods

‘ В случае отсутствия ошибок конфигурации сохраняются.

Conn.CoimnitTrans

Exit Function

Err_TestTrans:

‘В случае появления ошибок производится откат транзакции.

Conn.RollbackTrans

………………………..

EndFunction

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

Блокировка Oracle/SQL Server

При работе с Oracle, SQL Server, Informix либо хоть каким остальным серверным механизмом баз данных Access наиболее не производит управление блокировкой. Но основная теория остается постоянной — Access управляет доступом к записям в базе данных, обеспечивая почти всем юзерам одновременный доступ к ней.

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

При использовании Microsoft SQL Server могут применяться последующие типы блокировок:

• Shared Lock (Общая блокировка). Схожая блокировка употребляется в операциях обработки данных, доступных лишь для чтения. Общие блокировки разрешают остальным юзерам читать запись либо страничку, являющуюся объектом общей блокировки. На запись либо страничку может сразу налагаться несколько общих блокировок. Такие блокировки снимаются по окончании использова­ния данных.

• Exclusive Lock (Монопольная блокировка). Таковая блокировка употребляется при выполнении по от­ношению к данным операторов SQL UPDATE, DELETE
либо INSERT.
При всем этом на монопольно бло­кированные данные не могут налагаться никакие остальные блокировки до того времени, пока SQL Server не снимет монопольную блокировку.

• Live Lock (Временная блокировка). Схожая блокировка является запросом на монопольную бло­кировку, возникающим опосля 4 поочередных неудачных попыток внедрения монополь­ной блокировки данных. Таковая блокировка возникает в вариантах наличия очень огромного количества перекрывающихся общих блокировок. В схожей ситуации SQL Server перестает при­поменять общие блокировки. Временные блокировки предупреждают монополизацию таблицы либо странички общими блокировками (при операциях считывания) и воспрещают операции, связанные с записью (UPDATE, DELETE, INSERT).
Они также предупреждают ситуацию, именуемую «на­сыщением блокировки».

Есть и остальные применяемые SQL Server стратегии обработки заморочек одновременного досту­па. К ним относятся динамическая блокировка на уровне строчки (SQL Server 7.0), предотвращение, выявление и исправление обоюдной блокировки, управление жизнеутверждающей блокировкой, также наращивание масштабируемых блокировок.

Динамическая блокировка данных на уровне строчки подходящим диспетчером SQL Server дина­мически настраивает конфигурацию сервера блокировок, исходя из размера и черт использова­ния базы данных. Это в значимой степени уменьшает необходимость в ручной настройке и поддержке сервера блокировки.

При предотвращении, выявлении и исправлении обоюдной блокировки SQL Server выявляет момент появления конфликта 2-ух транзакций. В схожей ситуации выясняется, что одна транзакция моно­польно перекрыла данные, требуемые иной транзакцией, а та, в свою очередь, монопольно блоки­ровала данные, требуемые первой. Обе транзакции не могут снять свои блокировки. Без вмешательства механизма баз данных они остаются в состоянии обоюдной блокировки, для снятия которой SQL Server производит откат одной транзакции, завершает другую и опять запускает первую.

SQL Server интенсивно предутверждает обоюдные блокировки, существенно понижая количество блоки­ровок в таблицах.

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

Резюме

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

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

]]>