Подходит ли MS Access (JET) для многопользовательского доступа?

StackOverflow https://stackoverflow.com/questions/763888

  •  11-09-2019
  •  | 
  •  

Вопрос

У меня есть продукт, разработанный как настольный продукт, использующий файл MS Access в качестве базы данных.

Теперь некоторым пользователям необходимо установить его на нескольких компьютерах (скажем, на 2 или 3) и ПРЕДОСТАВИТЬ ОБЩИЙ доступ к базе данных.

Я думал поместить файл MS Access в общую папку и получить к нему доступ с компьютера, но...реактивный двигатель предназначен для многопользовательского доступа?

Есть какие-нибудь советы или вещи, о которых следует знать, делая это?

Редактировать:Приложение является .net, использующим базу данных в качестве хранилища (не использующим базу данных в качестве интерфейса)

Это было полезно?

Решение

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

  1. ядро базы данных Jet (это все, что здесь задействовано, как уточнил OP с помощью редактирования) по умолчанию является многопользовательским - оно было создано с нуля, чтобы быть таким.

  2. совместное использование хранилища данных Jet - это очень надежный, когда сеть не является некачественной.Это означает не глобальную сеть и не беспроводную, потому что пропускная способность должна быть достаточной, чтобы Jet мог поддерживать файл LDB (для многопользовательской блокировки), что означает пинг экземпляром Jet database engine на вашем локальном компьютере один раз в секунду (с настройками по умолчанию), и потому что Jet не может восстановиться после разрыва соединения (что довольно часто встречается в беспроводной среде).

  3. ситуация, при которой доступ прекращается, возникает, когда MDB приложения внешнего доступа является общим (что не относится к этому постеру).Причина, по которой это не удается, заключается в том, что вы делитесь вещами, которые не могут быть надежно разделены и у которых нет причин для совместного использования.Из-за способа, которым объекты Access хранятся в MDB-файле (весь проект Access хранится в одном большом двоичном объекте в одной записи в одной из системных таблиц), он очень подвержен повреждению, если его открывают несколько пользователей.По моей оценке, совместное использование интерфейса Access (или неразделенного MDB с таблицами и формами / отчетами / etc.all in one MDB) является источником 99,99% повреждений файлов Access / Jet.

Мой основной ответ на вопрос OP заключается в том, что да, Jet был бы отличным хранилищем данных для приложения такого размера.Однако, если есть хоть какая-то возможность того, что число пользователей превысит 25, то, возможно, было бы лучше начать с нуля с СУБД, которая более надежна при более высоком количестве пользователей.

Другие советы

Это вполне осуществимо сделать;но вы ДОЛЖНЫ разделить базу данных на внешний интерфейс (с формами, запросами, кодом) и внутренний интерфейс (только с данными).Каждый пользователь должен иметь внешний интерфейс на своем собственном компьютере, подключаясь к общему внутреннему интерфейсу.

Это будет медленно, поскольку Jet генерирует тонну сетевого трафика.Microsoft также постепенно отказывается от Access как инструмента разработки.Access 2007, например, имеет гораздо менее сложную модель безопасности, чем Access 2003.

Как давний разработчик Access, я постепенно отхожу от Access.

Не делай этого...Jet database утверждает, что может поддерживать нескольких пользователей, но использовать мастер изменения размера для преобразования вашего файла Access в базу данных Sql Express невероятно просто.Этот файл базы данных может быть легко заблокирован пользователем или администратором, и все ваши пользователи не смогут использовать базу данных.

...и Sql Express является бесплатным.Ваш путь обновления оттуда до полного экземпляра Sql Server или какой-либо другой коммерческой базы данных прост.

С 2 или 3 пользователями в надежной локальной сети все должно быть в порядке, при условии, что вы будете часто создавать резервные копии сетевого диска.

Избегайте любых полей bit / bool в ваших таблицах - у Jet есть некоторые неприятные проблемы с повреждением при множественном доступе к ним.

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

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

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

ACE / Jet engine - отличное программное обеспечение, но, пока оно было разработанный поддержка нескольких пользователей, фактическая поддержка нескольких пользователей на практике не является одной из его сильных сторон.Последней каплей для меня стало то, где затем была удалена безопасность пользовательского уровня (ULS) из движка:Я полагаю, я могу представить себе простую ситуацию с базой данных, где все пользователи будут иметь одинаковые привилегии (т.е.доступ администратора к ВСЕ объекты базы данных), но IMO, которые плохо поддерживают нескольких пользователей, по сравнению, скажем, с MS SQL Server.

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

Как системный администратор, пожалуйста, не используйте Access для чего-либо многопользовательского.Сделайте то, что предлагает Джефф Фриц, и используйте базу данных, предназначенную для многопользовательского доступа.Вы можете подумать, что вашим маленьким приложением будут пользоваться только несколько человек, но я гарантирую вам, что к концу года у него будет сто пользователей и пятьдесят новых функций.И если это все Access, а не VB / SQL Express, ваши оперативники однажды ночью ворвутся в ваш дом и перережут вам горло.

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

Это делалось так много раз многими разработчиками универсального программного обеспечения, когда мы видели, как .mdb повреждался в многопользовательской ситуации.Если так много опытных разработчиков-специалистов Access могут сделать это правильно, как я склонен полагать, то мы, специалисты широкого профиля, должно быть, делаем что-то неправильно, и это что-то должно быть довольно фундаментальным, но неочевидным, чтобы многие из нас убегали от этого с криком "Никогда больше!", Поэтому, если вы считаете себя опытным разработчиком-специалистом Access (или знаете, как его найти), тогда дерзайте.Но если вы специалист широкого профиля или случайный пользователь, ищущий легкий серверный сервер, то я предлагаю вам поискать в другом месте (SQL Server - это хороший IMO).

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

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

Я видел, что веб-сайты поддерживают многих пользователей, но я бы рекомендовал SQL Express, если только у вас нет веских причин выбирать Jet.

Я могу сказать вам по горькому опыту, что Jet 3/3.5 не был надежным.Я видел, как он часто выходил из строя при небольшой нагрузке, и когда происходили сбои, вы рисковали повредить данные.Раньше он был чрезвычайно чувствителен к любым проблемам с питанием, сбоям любого клиента (даже пользовательского интерфейса, связанного с mdb) и любым проблемам локальной сети.Более поздние версии Jet могли бы быть лучше, но, на мой взгляд, переход на Sql Server - это, безусловно, правильный путь для чего угодно, кроме тривиального ввода данных с небольшим числом пользователей.Sql Express бесплатен, и вы на самом деле ничего не теряете, особенно если ваш пользовательский интерфейс находится в .Net, а не Access.

Редактировать:Microsoft также не считает, что вам следует полагаться на Jet 4.

От: http://support.microsoft.com/kb/303528

Microsoft Jet не предназначен для использования с серверными приложениями с высокой нагрузкой, серверными приложениями с высоким уровнем параллелизма или серверными приложениями 24 часа в сутки, семь дней в неделю.Сюда входят серверные приложения, такие как веб-приложения, коммерческие приложения, транзакционные приложения и серверные приложения обмена сообщениями.Для приложений такого типа наилучшим решением является переход на настоящую клиент-серверную систему баз данных, такую как Microsoft Data Engine (MSDE) или Microsoft SQL Server.При использовании Microsoft Jet в приложениях с высокой нагрузкой, таких как Microsoft Internet Information Server (IIS), может возникнуть любая из следующих проблем:Повреждение базы данных Проблемы со стабильностью, такие как сбой или блокировка IIS Внезапный сбой или постоянный отказ драйвера подключиться к действительной базе данных, что требует повторного запуска службы IIS

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

Если вы используете сервер терминалов, производительность действительно хорошая.У нас есть больше решений для 50 пользователей в одном mdb Access.Разработка происходит очень быстро, а развертывание - легко.

Проблемы:

  • каждый может копировать данные mdb
  • нет прав доступа
  • ограниченные процедуры хранения
  • оптимизация (сжатие и восстановление) возможна только без использования базы данных данных
  • ограничение до 2 ГБ!
Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top