Access. Особливості роботи в многопользовательском режимі., MS Office, Програмні керівництва, статті

 

 


Після створення програми Access воно залишає середовище розробки і направляється для використання замовниками. При цьому можуть виникнути проблеми, пов’язані з роботою цього додатка в багатокористувацької середовищі. Найбільш серйозною з цих проблем є вирішення конфліктів, що виникають при одночасному зверненні декількох користувачів до записів бази даних Access.


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


Важливо пам’ятати, що робота з базою даних в багатокористувацької середовищі може викликати проблеми, пов’язані з блокуванням даних і конфліктами доступу до них. Придушення повідомлень про помилки, недостатнє увагу до подібних питань або надія на сприятливий збіг обставин не вирішує проблему. Незважаючи на гадану складність роботи в багатокористувацької середовищі, зрозуміти механізм дії блокування даних і спосіб обслуговування механізмом Jet декількох користувачів досить просто. Нехтування подібними питаннями, як правило, призводить до виникнення більш складних проблем, які зачіпають користувачів, клієнтів і впливають на репутацію розробника. Якщо для програми не передбачено ефективне вирішення питань роботи в багатокористувацької середовищі, при роботі з ним неминуче будуть виникати такі проблеми:


• Нові записи не зберігаються. Після введення інформації користувач виявляє, що в базі даних вона не з’явилася. Якщо подібна помилка не повторюється, це говорить не про відсутність проблеми, а про ненадійність додатки.


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


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


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


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


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


• Мережеве розміщення. У даній конфігурації єдиний MDB-файл розташовується на мережевому сервері, і користувачі отримують доступ до бази даних при зверненні до сервера. Дані та виконувані модулі можуть міститися в єдиному MDB-файлі або розміщуватися на файловому сервері у вигляді декількох окремих файлів. Перевагою даної конфігурації є простота підтримки, оскільки при необхідності в оновлення потребує лише виконуваний файл. Однак, оскільки всі форми, звіти, модулі, запити, ЕХЕ-файли Access, а також всі бібліотеки DLL і т.п. повинні передаватися по мережі на робочу станцію, мережевий трафік невиправдано зростає, а продуктивність значно знижується. Ймовірно, в подібних конфігураціях слід використовувати пов’язані форми. Далі розглядаються проблеми зв’язування форм з даними і виникають при цьому конфлікти доступу.


• Розділена база даних з розміщеними в мережі даними. Така конфігурація за традицією називається конфігурацією віддаленої бази даних (відзначимо, що значення слова “віддалена” в надзвичайно динамічну епоху Internet поступово змінюється і незабаром може застаріти), оскільки дані відокремлені від виконуваного модуля або програмного коду, хоча механізм баз даних і залишається локальним. На відміну від конфігурації клієнт-сервер, механізм баз даних 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 (Режим відкриття, певний за замовчуванням). Тут можна визначити режим відкриття бази даних, тобто чи повинна вона відкриватися для монопольного доступу (тільки для одного користувача на весь сеанс роботи) або для загального доступу.


Якщо обраний режим 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), імовірність конфлікту двох користувачів під час її редагування нижче, ніж при одночасній блокування кількох записів у схемі сторінкової блокування. Раніше вірогідність конфлікту множилася на число записів на сторінці, визначення якого було утруднено. Кількість записів на сторінці даних залежало від розміру записів і від часу їх введення, тому передбачити ймовірність конфлікту було важко.


Режим блокування на рівні рядка визначений за замовчуванням, але це не означає, що він у всіх випадках є оптимальним. Якщо першочерговим завданням ставиться продуктивність програми, а конфлікти виникають досить рідко або піддаються контролю, такий спосіб блокування може привести до зниження продуктивності. Розглянемо приклад комп’ютерної системи банку, що здійснює міжнародні торговельні операції, в якій введення записів проводиться набагато частіше, ніж їх редагування. Оскільки для подібної системи надзвичайно важлива висока продуктивність, а її зниження допускається лише в разі конфлікту, інші операції бази даних повинні виконуватися з максимально можливою швидкістю. У подібному випадку може використовуватися сторінкова блокування.


З іншого боку, якщо до бази даних повинен забезпечуватися доступ багатьох користувачів, а одночасне редагування кожним користувачем більше одного запису неприпустимо, можливе застосування блокування на рівні рядки. Це тим більше вірно при активному редагуванні бази даних. Повертаючись до прикладу банківської системи, слід зазначити, що записи бази даних з інформацією про депозити і вилучення з рахунків клієнтів повинні бути легкодоступні. При редагуванні запису її слід блокувати, в іншому випадку існує ризик, що внесені користувачем зміни будуть перезаписані конкуруючим користувачем. Більш того, редагування одного запису не повинно перешкоджати редагуванню сусідній записи іншим користувачем. Блокування на рівні рядка може застосовуватися в ситуаціях, коли запис повинна залишатися відкритою якийсь час, протягом якого її не можуть редагувати інші користувачі. Прикладом може служити перегляд інформації про клієнта для підведення балансу або оцінки його кредитоспроможності. До завершення перегляду та прийняття рішення змінювати запис небажано. Якщо запис залишається відкритою протягом декількох хвилин, бажано уникати блокування кількох інших записів на час її редагування. Як правило, слід уникати навіть одного запису в протягом досить довгого періоду часу, якщо тільки це не є абсолютно необхідним.


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


LDB-файл


Файл блокування – це спеціальний тимчасовий файл, що створюється при відкритті бази даних Access. Він містить інформацію про застосовувані в базі даних блокування, а також про її користувачів. При закритті бази даних файл видаляється. Його ім’я збігається з ім’ям відповідної бази даних, але він має розширення LDB. Цей файл завжди розташовується в тому ж каталозі, що і база даних.


Порівняння оптимістичною, песимістичній блокувань і блокування на рівні рядка


Розробник може справедливо припускати, що в многопользовательском додатку рано чи пізно виникне конфлікт доступу при зверненні до однієї і тієї ж записи. Єдине розумне рішення такої проблеми полягає у виборі відповідних параметрів блокування. Існує два варіанти блокування: оптимістична і песимістична.


Оптимістична блокування


Оптимістична блокування використовується в Access за умовчанням, вона проста в реалізації, і зазвичай перевагу віддають саме їй. При оптимістичній блокуванні записи передбачається, що конфлікти доступу малоймовірні і що запис блокується лише в момент її фактичного поновлення. Це забезпечує високу ступінь доступності даних, оскільки право довготривалого або виняткового доступу до них нікому не надається. Відповідно до вищесказаним при відкритті записи для редагування інші користувачі також можуть відкривати її для редагування, причому перевага збереження внесених змін має перший користувач. Хоча оптимістична блокування проста в реалізації і звичайно не породжує проблем доступу користувачів до своїх даних, проте при її використанні одним з найбільш важливих питань роботи з базами даних в багатокористувацької середовищі є питання про те, чиї зміни слід зберігати. Коли користувач А відкриває запис для редагування і накладає на неї оптимістичну блокування, ніщо не заважає користувачеві Б відкрити цю ж запис для внесення змін. Якщо Б збереже зміни раніше, ніж це зробить А, користувач А отримає таке повідомлення:

“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 is exclusively locked. (База даних <ім'я> використовується в монопольному режимі.)


3008

The table 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 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 on machine . (Збереження неможливо. Об’єкт блокований користувачем <ім'я> на комп’ютері <ім'я>.)

3187

Couldn “t read; currently locked by user on machine . (Читання неможливо. Об’єкт блокований користувачем <ім'я> на комп’ютері <ім'я>.)

3188

Couldn “t update; currently locked by another session on this machine. (Оновлення неможливо. Об’єкт блокований протягом іншого сеансу роботи на цьому комп’ютері.)

3189

Table is exclusively locked by user on machine . (Таблиця <ім'я> блокована в монопольному режимі користувачем <ім'я> на комп’ютері <ім'я>.)

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 зупинив процес внаслідок одночасної спроби двох користувачів змінити одні й ті ж дані.)

3202

Couldn “t save; currently locked by another user. (Збереження неможливо. Об’єкт блокований іншим користувачем.)

3211

The database engine couldn “t lock table 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 on machine . (Оновлення неможливо. Об’єкт блокований користувачем <ім'я> на комп’ютері <ім'я>.)

3260

Table is exclusively locked by user on machine . (Таблиця <ім'я> блокована в монопольному режимі користувачем <ім'я> на комп’ютері <ім'я>.)

3261

Couldn “t lock table ; currently in use by user on machine . (Блокування таблиці <ім'я> неможлива. Таблиця використовується користувачем <ім'я> на комп’ютері <Ім'я>.)

 


Масив помилок також містить й іншу потенційно корисну інформацію про помилку блокування: дані про блокування, що використовується іншим користувачем. Властивості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 поспішно створюються людьми, які не завжди досить добре розбираються в питаннях багатокористувацького застосування. Принаймні, така обробка конфлікту записи є рішучою і остаточною, а користувачам не доведеться шукати відповідь на питання, над яким вони ніколи не замислювалися. Якщо додаток повинно обробляти конфлікт записи іншим способом, необхідно створити для користувача процедуру обробки помилки.


Блокована запис


Коли в ході звичайного використання програми користувач А намагається змінити запис, що редагується користувачем Б, перший з них отримає повідомлення про помилку 3260 (Запис блокована – див. табл. 4). Як правило, підпрограма обробки помилок робить задане число спроб збереження запису користувача А перед тим, як запропонувати йому підтвердити необхідність подальших спроб або відмовитися від зміни запису. Якщо застосована користувачем Б блокування є песимістичною, вона знімається відразу після поновлення запису в базі даних. Як правило, цей період часу дуже короткий.


Транзакції


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


Однакб транзакції мають не одні лише переваги. Щоб забезпечити виконання всіх змін транзакція збирає інформацію про блокування. Транзакції встановлюють всі необхідні додатком блокування і не знімають їх до завершення всього процесу, при цьому помилки виникати не повинні. Оскільки існує ймовірність установки великої кількості блокувань і час їх дії виявляється більш тривалим, ніж якби вони встановлювалися тільки частиною всього процесу, можливість одночасного доступу багатьох користувачів при зверненні програми до даних в дійсності знижується. Проте в будь-якому випадку база даних, що допускає використання великою кількістю користувачів, але не забезпечує цілісність даних, цінується невисоко. Тому компроміс між цілісністю даних і можливістю доступу з боку багатьох користувачів є виправданим.


Транзакції є методами об’єкта ADOConnection. У табл. 6 описуються три таких методу.

Таблиця 6 Визначення транзакції
















Метод

Опис


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 (Монопольна блокування). Таке блокування використовується при виконанні по відношенню до даних операторів SQLUPDATE, DELETE абоINSERT. При цьому на монопольно блоковані дані не можуть накладатися ніякі інші блокування до тих пір, поки SQL Server не зніме монопольну блокування.


• Live Lock (Тимчасове блокування). Подібна блокування є запитом на монопольну блокування, що виникають після чотирьох послідовних невдалих спроб застосування монопольної блокування даних. Таке блокування виникає у випадках наявності занадто великої кількості перекриваються загальних блокувань. У подібній ситуації SQL Server перестає застосовувати загальні блокування. Тимчасові блокування запобігають монополізацію таблиці або сторінки загальними блокуваннями (при операціях зчитування) і забороняють операції, пов’язані із записом (UPDATE, DELETE, INSERT). Вони також запобігають ситуацію, яка називається “насиченням блокування”.


Існують і інші використовувані SQL Server стратегії обробки проблем одночасного доступу. До них відносяться динамічна блокування на рівні рядка (SQL Server 7.0), запобігання, виявлення та виправлення взаємного блокування, управління оптимістичній блокуванням, а також нарощування масштабованих блокувань.


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


При запобіганні, виявленні та виправленні взаємного блокування SQL Server виявляє момент виникнення конфлікту двох транзакцій. У подібній ситуації з’ясовується, що одна транзакція монопольно блокувала дані, необхідні інший транзакцією, а та, в свою чергу, монопольно блокувала дані, необхідні першої. Обидві транзакції не можуть зняти свої блокування. Без втручання механізму баз даних вони залишаються в стані взаємного блокування, для зняття якої SQL Server здійснює відкат однієї транзакції, завершує іншу і знову запускає першу.


SQL Server активно запобігає взаємні блокування, значно зменшуючи кількість блокувань в таблицях.


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


Резюме


У цьому розділі досліджувалися питання роботи в багатокористувацької середовищі, починаючи з конфігурування файлу бази даних і закінчуючи вибором наборів записів і роботою зі сторінками і записами даних. Детально розглядалися різні стратегії блокування, порівнювалися методи оптимістичній і песимістичній блокування, описувалися переваги нових можливостей механізму баз даних Jet при блокуванні на рівні рядки. Наводилися аргументи вибору застосовуваних додатком типів блокування, а також давалися поради щодо використання повідомлень про помилки, що надходять від постачальника OLEDB. В цілому ця глава покликана допомогти у виробленні ефективної стратегії і тактики при створенні нової програми, вона може також виявитися корисною і при налагодженні існуючої бази даних.


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

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*