MS Access (JET) подходит для многопользовательского доступа?
У меня есть продукт, предназначенный для настольного продукта с использованием файла MS Access в качестве БД.
теперь некоторым пользователям необходимо установить его на несколько ПК (скажем, 2 или 3) и поделиться базой данных.
Я думал поместить файл MS Access в общую папку и получить к нему доступ с ПК, но... реактивный двигатель предназначен для множественного доступа пользователей?
любые советы или вещи, чтобы быть в курсе этого?
изменить: Приложение является .net, используя базу данных как хранение (не используя базу данных в качестве интерфейса)
13 ответов
в ответах в этой теме так много дезинформации, что я не знаю, с чего начать. Я только что потратил 4 балла на репутацию, голосуя за ответы с вводящей в заблуждение и неправильной информацией в них.
движок базы данных Jet (который является всем, что здесь задействовано, как уточнил OP с помощью редактирования) по умолчанию многопользовательский-он был построен с нуля, чтобы быть таким.
совместное использование хранилища данных Jet-это очень надежный, когда сеть не является некондиционной. Это означает, что не WAN и не беспроводной, потому что полоса пропускания должна быть достаточной для Jet для поддержания файла LDB (для многопользовательской блокировки), что означает пинг экземпляром локального компьютера JET database engine один раз в секунду (с настройками по умолчанию), и потому что Jet не может восстановиться после отброшенного соединения (что довольно распространено в беспроводной среде).
ситуация, когда доступ падает вниз, когда интерфейс Доступ к приложению MDB является общим (что не относится к этому плакату). Причина неудачи в том, что Вы делитесь вещами, которые не могут быть надежно разделены и не имеют причин для совместного использования. Из-за того, как объекты Access хранятся в файле MDB (весь проект Access хранится в одном поле BLOB в одной записи в одной из системных таблиц), он очень подвержен повреждению, если его открывают несколько пользователей. По моей оценке, совместное использование интерфейса доступа (или неразрезанного MDB с таблицами и формы / отчеты / etc. all in one MDB) является источником 99,99% повреждений файлов Access/Jet.
мой основной ответ на вопрос OP заключается в том, что, да, Jet будет отличным хранилищем данных для приложения такого размера. Тем не менее, если есть какая-либо возможность для пользователей вырасти выше 25, то, возможно, было бы лучше начать с нуля с движка базы данных, который является более надежным при более высоких популяциях пользователей.
Это вполне возможно сделать, но вы должны разделить базу данных на переднем конце (формы, запросы, код) и задний конец (только данные). Каждый пользователь должен иметь передний конец на своем компьютере, связываясь с общим задним концом.
Это будет медленно, так как Jet генерирует тонну сетевого трафика. Microsoft также постепенно осуждает Access как инструмент разработки. Например, Access 2007 имеет гораздо менее сложную модель безопасности, чем Access 2003.
как разработчик доступа долгое время я постепенно отдаляюсь от доступа.
Не делай этого... база данных Jet утверждает, что может поддерживать несколько пользователей, но невероятно легко использовать мастер увеличения для преобразования файла доступа в базу данных Sql Express. Этот файл базы данных может быть легко заблокирован пользователем или администратором, и все пользователи не смогут использовать базу данных.
... и Sql Express является бесплатным. Путь обновления оттуда до полного экземпляра Sql Server или какой-либо другой коммерческой базы данных простой.
с 2 или 3 пользователями в надежной локальной сети вы должны быть в порядке, если вы часто поддерживаете сетевой диск.
избегайте любых бит / bool полей в ваших таблицах-Jet имеет некоторые неприятные проблемы с коррупцией с множественным доступом к ним.
также имейте в виду, что все блокировки доступа оптимистичны: вы будете получать грязные чтения изредка.
MS Access предназначен для небольших сценариев office, таких как: некритическое использование light office, которое можно настроить с помощью минимум программирования.
ожидайте, что файл данных будет поврежден время от времени-резервное копирование регулярно.
ACE / Jet engine-отличная часть программного обеспечения, но, хотя это было designed для поддержки нескольких пользователей, на самом деле поддержка нескольких пользователей на практике не одна из его сильных сторон. Последней каплей для меня является то, где затем удалена безопасность уровня пользователя (ULS) из движка: я полагаю, что могу представить простую ситуацию с базой данных, где все пользователи будут иметь одинаковые привилегии (т. е. доступ администратора к все объекты базы данных), но IMO, который не поддерживает нескольких пользователей ну, по сравнению, скажем, С MS SQL Server.
Да, он поддерживает доступ несколькими (то есть небольшим, размером с рабочую группу, числом) пользователей через общий сетевой файл. Однако архитектура общего файлового ресурса просто не идеальна для поддержки одновременной записи в файл несколькими пользователями. Системы клиент/сервер базы данных (SQL Server и др.) как правило, обеспечивает лучшую производительность, безопасность и надежность.
как сисадмин, пожалуйста, не используйте доступ для чего-либо многопользовательского. Делайте то, что предлагает Джефф Фриц, и используйте базу данных, предназначенную для многопользовательского доступа. Вы можете подумать, что ваше маленькое приложение будет доступно только нескольким людям, но я Гарантирую Вам, что к концу года у него будет сто пользователей и пятьдесят новых функций. И если это все Доступ, а не VB / SQL Express, ваши люди Ops ворвутся в ваш дом однажды ночью и разрежут ваш горло.
Access не является клиент-серверным приложением и предоставляет очень мало возможностей для резервного копирования/восстановления или какой-либо автоматизации. Не говоря уже о том, что интерфейс и БД очень тесно связаны... так что если вы когда-нибудь захотите превратить это в веб-приложение, или делать какие-либо серьезные изменения, ваш мир будет наполнен болью.
Это было сделано так много раз так много общих инженеров программного обеспечения, где мы видели.mdb поврежден в многопользовательской ситуации. Если так много опытных специалистов-разработчиков доступа могут сделать это правильно, как я склонен верить, то мы, универсалы, должны делать что-то неправильно, и что-то должно быть довольно фундаментальным, но не очевидным для многих из нас, чтобы убежать от вещи, кричащей " никогда больше!"Поэтому, если вы считаете себя опытным разработчиком доступа специалиста (или вы знаете, как найти один), то пойти на это. Но если вы универсалист или случайный пользователь, ищущий легкий задний конец, я предлагаю вам искать в другом месте (SQL Server-хорошая ИМО).
Если ваши пользователи могут ждать в два раза дольше для приложения с половиной функций, которые они хотят, то не используйте Access.
Jet не имеет сложной логики блокировки, необходимой для поддержки многопользовательских сценариев. Вы можете уйти с его помощью, если ваше приложение в основном читает и с низким уровнем конкуренции.
Я видел, что веб-сайты поддерживают многих пользователей, но я бы рекомендовал SQL Express, если у вас нет веской причины выбрать Jet.
Я могу сказать вам из болезненного опыта, что Jet 3/3.5 не было надежным. Я видел, что он часто падает под легкой нагрузкой, и когда были сбои, вы рисковали повреждением данных. Раньше он был чрезвычайно чувствителен к любым проблемам с питанием, любому клиенту, врезающемуся в него (даже пользовательский интерфейс, связанный с mdb), и любым проблемам LAN. Более поздние версии Jet могут быть лучше, но переход на Sql Server-это, на мой взгляд, путь к чему-либо, кроме тривиального ввода данных с небольшим число пользователей. Sql Express бесплатен, и вы ничего не теряете, особенно если ваш пользовательский интерфейс находится в .Net, а не в Access.
EDIT: Microsoft не считает, что вы также должны полагаться на Jet 4.
from: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 доступа. Разработка осуществляется очень быстро и легко.
проблемы:
- каждый может копировать данные mdb
- нет права доступа
- ограниченные процедуры хранения
- оптимизация (сжатие и восстановление) возможна только без использования базы данных данных
- ограничение до 2 ГБ!