Настройка базы данных MS-Access для многопользовательского доступа

Ответ 1

Я нахожу ответы на этот вопрос проблематичными, запутанными и неполными, поэтому я постараюсь сделать лучше.

Q1: Как мы можем убедиться, что пользователь записи может вносить изменения в данные таблицы, а другие пользователи используют данные? Используют ли пользователи-читатели блокировки на таблицах? Должен ли пользователь записи помещать блокировки в таблицу? Предоставляет ли Access это для нас или мы должны явно это кодировать?

Никто не ответил на это в полной мере. Информация о настройке блокировок в параметрах доступа не имеет ничего общего с чтением и блокировкой записи. No Locks vs. All Records vs. Edited Record - это то, как вы устанавливаете блокировку записей по умолчанию для WRITES.

• Никакие блокировки не означают, что вы используете блокировку OPTIMISTIC, что означает, что вы разрешаете нескольким пользователям редактировать запись, а затем сообщать об этом после того, как запись изменилась с тех пор, как они начали свои собственные изменения. Оптимистическая блокировка - это то, с чего вам следует начинать, поскольку для ее реализации не требуется кодирование, а для небольших пользователей это вряд ли когда-либо вызывает проблему.

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

• Отредактированная запись означает, что меньше записей заблокировано, но независимо от того, установлена ​​ли одна запись или более одной записи, установлена ​​ли ваша база данных для использования блокировки уровня записи (сначала добавлена ​​в Jet 4) или блокировка на уровне страницы. Честно говоря, я никогда не думал, что стоит установить блокировку на уровне записи, поскольку оптимистическая блокировка позаботится о большинстве проблем.

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

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

Я бы вообще не реализовал Jet ULS и вместо этого просто архитектор форм редактирования данных, чтобы они проверяли вход пользователя в систему Windows и делали формы доступными только для чтения или записываемые в зависимости от того, какие пользователи должны получать доступ. Независимо от того, хотите ли вы записывать членство в группе в таблице данных или поддерживать группы безопасности Windows для этой цели, зависит от вас. Вы также можете использовать файл рабочей группы Jet для работы с ним и предоставить другой файл system.mdw для пользователей записи. Пользователи, доступные только для чтения, будут регистрироваться прозрачно как admin, а пользователям, входящим в систему как admin, предоставляется доступ только для чтения. Пользователи записи будут входить в систему как другое имя пользователя (прозрачно, в ярлыке, который вы предоставляете для запуска приложения, не предоставляя пароль), и это будет использоваться для настройки форм как чтение или запись.

Если вы используете Jet ULS, это может стать действительно волосатым, чтобы все исправить. Он включает блокировку всех таблиц как только для чтения (или, возможно, даже не для этого), а затем с использованием запросов RWOP для обеспечения доступа к данным. Я не сделал этого, кроме одного такого приложения за 14 лет профессионального развития Access.

Подводя итог моим ответам на части вашего вопроса:

Как мы можем убедиться, что пользователь записи может вносить изменения в данные таблицы, а другие пользователи используют данные?

Я бы рекомендовал сделать это в приложении, установив формы для чтения/только или редактируемые во время выполнения в зависимости от входа пользователя в систему. Самый простой способ - установить, чтобы ваши формы были доступны только для чтения и изменялись для редактирования для пользователей, когда они открывают форму.

Используют ли пользователи-читатели блокировки таблиц?

Не имеет смысла. У Jet/ACE есть блокировки чтения, но они существуют только с целью сохранения состояния для отдельных просмотров и для обновления данных для пользователя. Они не блокируют операции записи любого рода, хотя накладные расходы на их отслеживание теоретически замедляют работу. Этого недостаточно, чтобы беспокоиться.

Должен ли пользователь записи помещать блокировки в таблицу?

Доступ в сочетании с Jet/ACE делает это автоматически, особенно если вы выбрали оптимистичную блокировку по умолчанию. Ключевым моментом здесь является то, что приложения Access являются привязкой к базе данных, поэтому, как только форма загружается, запись имеет блокировку чтения, и как только запись будет отредактирована, независимо от того, заблокирована ли она для других пользователей, определяется ли она используете ли вы оптимистичную или пессимистичную блокировку. Опять же, это то, что Access заботится о вас с поведением по умолчанию в связанных формах. Вы ни о чем не беспокоитесь, пока не столкнетесь с проблемами.

Предоставляет ли Access это для нас или мы должны явно указывать это?

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

Q2: Существуют ли какие-либо общие проблемы с "транзакциями MS Access", о которых мы должны знать?

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

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

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

Теперь несвязанные формы на самом деле довольно просто реализовать в Access (особенно, если вы назовете, что ваши элементы редактирования управляются так же, как и базовые поля), но при использовании несвязанных форм редактирования данных действительно отсутствует точка доступа к Access, привязка сделана для вас. И основным недостатком перехода является то, что вы теряете все события формы на уровне записи, такие как OnInsert, BeforeUpdate и т.д.

Q3. Можем ли мы работать с формами, запросами и т.д., Пока они используются? Как мы можем "программировать", не мешая пользователям?

Это один из вопросов, которые были хорошо рассмотрены. Все многопользовательские или реплицированные приложения Access должны быть разделены, и большинство однопользовательских приложений также должны быть. Это хороший дизайн, а также делает приложения более стабильными, так как только таблицы данных в конечном итоге открываются более чем одним пользователем за раз.

Q4. Какие настройки в MS Access влияют на то, как обрабатываются вещи?

"вещи?" Какие вещи?

Q5. Наш опыт работы в основном связан с Oracle, где Access отличается при работе с несколькими пользователями? В Access есть такие вещи, как "уровни изоляции"?

Я не знаю ничего конкретно о Oracle (ни один из моих клиентов не мог позволить себе это, даже если бы они этого захотели), но попросив сравнение Access и Oracle предает фундаментальное недоразумение где-то вдоль линии.

Доступ - это инструмент разработки приложений.

Oracle - это сервер базы данных промышленной силы.

Яблоки и апельсины.

Теперь, конечно, Access поставляется с механизмом базы данных по умолчанию, первоначально называемым Jet, и теперь переработан и переименован в ACE, но есть много уровней, на которых доступ к платформе разработки можно полностью отключить от Jet/ACE, механизма базы данных по умолчанию,

В этом случае вы решили использовать заднюю часть Jet/ACE, которая, вероятно, будет очень удобной для небольших пользовательских групп, то есть до 25. Jet/ACE также может быть до 50 или 100, в частности когда только несколько из одновременных пользователей имеют разрешение на запись. Хотя ограничение 255 пользователей в Jet/ACE включает в себя как пользователей, предназначенных только для чтения, так и пользователей записи, количество пользователей, которые действительно контролируют количество одновременных пользователей, которых вы можете поддерживать, и в вашем случае у вас есть приложение, в основном читаемое - только пользователи, поэтому не должно быть сложно создать хорошее приложение, у которого нет проблем с задним концом.

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

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

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

Если вы обнаружите, что пишете много кода, тогда вам, вероятно, не хватает точки доступа.

Ответ 2

Первое, что нужно сделать (если это еще не сделано) - разбить вашу базу данных на передний план (со всеми формами/отчетами и т.д.) и обратно (со всеми данными). Во-вторых, нужно настроить управление версиями на передней панели.

То, как я сделал это во многих моих базах данных, заключается в том, чтобы пользователи запускали небольшую базу данных "перемычек", чтобы открыть основную базу данных. Эта перемычка выполняет следующие действия:

• Проверяет, имеет ли пользователь базу данных на своем диске C

• Если они не устанавливают и не запускают

• Если они это сделают, проверьте, какая у них версия

• Если номера версий не совпадают, то скопируйте последнюю версию

• Откройте базу данных

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

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

Ответ 3

Стол или блокировка записи доступны в Access во время записи данных. Вы можете управлять блокировкой записи по умолчанию с помощью Tools | Варианты | Вкладка "Дополнительно":

• Без замков
• Все записи
• Отредактированная запись

Вы можете установить это в форме Записи Записи или в вашем коде DAO/ADO для определенных нужд.

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

Лучшая практика: отделите свои таблицы от всего вашего другого кода. Дайте каждому пользователю собственную копию файла кода, а затем передайте файл данных на сетевом сервере. Работайте над "тестовой" копией кода (и ссылкой на файл тестовых данных), а затем отдельно обновляйте отдельные отдельные файлы кода. Если вам нужно внести изменения в файл данных (добавьте таблицы, столбцы и т.д.), Вам нужно будет все пользователи выйти из приложения, чтобы внести изменения.

См. другие ответы для сравнения Oracle.

Ответ 4

Я думаю, что доступ - лучший выбор для вашего дела. Но вам нужно разбить базу данных, см. http://accessblog.net/2005/07/how-to-split-database-into-be-and-fe.html

• Как мы можем убедиться, что пользователь записи может вносить изменения в данные таблицы, а другие пользователи используют данные? Используют ли пользователи-читатели блокировки на таблицах? Должен ли пользователь записи помещать блокировки в таблицу? Предоставляет ли Access это для нас или мы должны явно его кодировать?

нет блокировок чтения, если вы не разместите их явно. Просто используйте "Без замков"

• Существуют ли какие-либо общие проблемы с "транзакциями MS Access", о которых мы должны знать?

не должно быть проблем с 1-2 пользователями записи

• Можем ли мы работать с формами, запросами и т.д., пока они используются? Как мы можем "программировать", не мешая пользователям?

если вы разделите базу данных - тогда нет проблем с работой над дизайном FE.

• Какие настройки в MS Access влияют на то, как обрабатываются вещи?

Что ты имеешь в виду?

• Наш опыт в основном связан с Oracle, где Access отличается при обработке нескольких пользователей? В Access есть такие вещи, как "уровни изоляции"?

нет уровней изоляции в доступе. BTW, вы можете позже переместить данные в oracle и сохранить интерфейс доступа, если у вас много пользователей и большая база данных.

Ответ 5

Доступ - отличная многопользовательская база данных. Он имеет множество встроенных функций для обработки многопользовательской ситуации. На самом деле, это так популярно, потому что это такая большая многопользовательская база данных. Существует верхний предел того, сколько пользователей могут использовать базу данных одновременно с выполнением обновлений и изменений - в зависимости от того, насколько хорошо осведомлен разработчик о доступе и как была создана база данных - от 20 пользователей до примерно 50 пользователей. Некоторые базы данных доступа могут быть созданы для обработки до 50 одновременных пользователей, в то время как многие другие могут обрабатывать 20 или 25 одновременных пользователей, обновляющих базу данных. Эти цифры были отмечены для баз данных, которые использовались в течение нескольких или более лет и много раз обсуждались в группах новостей доступа.

Ответ 6

Я нашел протокол SMB2, введенный в Vista, чтобы заблокировать базы данных доступа. Его можно отключить с помощью следующего regedit:

Редактор реестра Windows версии 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters] "SMB2" = DWORD: 00000000

Ответ 7

Правильный способ создания клиент-серверных приложений Microsoft Access, где данные хранятся в СУБД, заключается в использовании метода Linked Table. Это обеспечивает изоляцию данных и Concurrency поддерживается между клиентским приложением Microsoft Access и данными РСУБД без дополнительной и ненужной логики программирования и кода, что затрудняет техническое обслуживание и увеличивает время разработки.

см. http://claysql.blogspot.com/2014/08/normal-0-false-false-false-en-us-x-none.html