Системы баз данных Jet и ACE могут поддерживать 255 пользователей, а не только 255 одновременных подключений. Это связано с тем, что стандартом взаимодействия с хранилищем данных Jet / ACE является отдельное соединение для каждого пользователя, которое открывается и затем повторно используется в течение сеанса. Тем не менее, это определенно тот случай, когда при обычном использовании Jet / ACE может открыть более одного соединения на пользователя, поэтому 255 даже не является надежным теоретическим пределом.
Jet / ACE взаимодействует с файлом данных и поддерживает блокировку через свой файл блокировки (* .LDB). Конкуренция за файл данных и файл LDB может легко превзойти способность файловой системы поддерживать ее, поэтому в целом практическое ограничение на количество пользователей намного ниже теоретического ограничения 255 (вы заметите, что 255 на единицу меньше, чем степень 2, подсказка, подсказка).
В реальных сценариях правильно разработанное приложение Access с хранилищем данных Jet / ACE, работающее в надежной сети и хранящееся на сервере с собственной файловой системой Windows, может быть достаточно стабильным для диапазона 20-30 пользователей. Но это зависит от того, что делают эти пользователи. Чем больше данных доступно только для чтения, тем выше число одновременных пользователей, которые могут поддерживаться.
Опытные разработчики Access сообщают, что инженерные приложения могут работать со 100 одновременно работающими пользователями, но в этот момент вам, как правило, приходится переписывать как несвязанное приложение, и тогда вы отказываетесь от большинства преимуществ Access как переднего плана. чтобы ухаживать за бэкендом, который лучше использовать с меньшим количеством пользователей.
Мое основное правило заключается в том, что каждый раз, когда численность пользователей достигает 15 одновременных пользователей, я начинаю говорить с клиентом об увеличении размера до SQL Server не потому, что это необходимо, а потому, что им нужно привыкнуть к мысли, что с ростом использования они будут нуждаться в увеличении. То, что происходит с 15 пользователями или с 20 или 30, зависит от характера конкретного приложения. Как я уже говорил выше, если большинство пользователей доступны только для чтения в течение большей части своего сеанса, у вас больше запаса, чем если бы все добавляли / обновляли записи большую часть времени.
Учитывая, что приложение C # будет несвязанным приложением, я не думаю, что 30 пользователей должны быть ужасно проблемными, но я не программист C #. Если это новая разработка и есть вероятность того, что численность пользователей вырастет за пределы 30 пользователей, мне просто не составит труда построить серверную часть, а не Jet / ACE.