最大并发连接数（以毫秒为单位）
ms-access 支持的最大并发连接数是多少？
What are the maximum concurrent connections ms-access supports?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
ms-access 支持的最大并发连接数是多少？
What are the maximum concurrent connections ms-access supports?
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
接受 或继续使用网站，即表示您同意使用 Cookies 和您的相关数据。
发布评论
评论（3）
理论上 255，实际上这要看情况。如果它们大多是只读的，并且您所在的网络速度很快，那么我已经在编写良好的数据库上看到过 100 多个没有问题的数据库。另一方面，我确信会出现同样的旧恐怖故事，即数据库因 2 个用户而损坏。是的，这可能会发生，但如果你创建了一个好的数据库并且对你用它做什么是现实的，你可以让数量惊人的用户挂起一个数据库。
从长远来看，您可能希望考虑免费（Express）版本的 SQL Server 以获得更高的用户数量。
In theory 255, in practice well it’s depends. If they are mostly read only and the network you are on is fast then I have seen 100+ with no problems on a well written database. On the other hand I’m sure the same old horror stories of databases getting corrupt with 2 users will come up. Yes it can happen but if you make a good database and are realistic about what you do with it you can get a surprising number of users hanging off one.
In the long term you might want to look at the free (Express) version of SQL server for higher user counts.
从字面上看，“Jet 数据库引擎版本 1.1、2.0 和 2.5 只能由任何一台计算机上的 10 个客户端应用程序同时使用”。从 Jet 3.0 开始，没有这样的限制。
请参阅此链接：
http://support.microsoft.com/default.aspx?scid =kb;en-us;154869
Literally, "the Jet database engine versions 1.1, 2.0, and 2.5 can only be used by 10 client applications simultaneously on any one machine". Starting from Jet 3.0 there is no such limitation.
See this link:
http://support.microsoft.com/default.aspx?scid=kb;en-us;154869
根据我的经验，10 个并发用户开始引起问题。
我确信有一些例子可以让非常小的数据集在许多用户中运行良好。
对于某些应用程序来说，访问可能没问题。这条线索似乎充满了热情。
这里要理解的关键概念是没有服务器。每个查询都会通过网络拉取整个表。
如果是 JOIN，则每个查询都会拉取网络上涉及的每个表。
这是因为 JOIN 引擎位于您的桌面上。
访问文件在哪里并不重要。最好的情况是，它位于主要用户的台式机上。其他人都必须利用网络来访问数据。
如果你有一个 100k 的表并且你想要 id #1042，你将通过网络拉取 100k * 记录长度的数据，然后过滤掉除 #1042 之外的所有内容。它无法缓存，因为您的同事可能已经更改了您要查看的下一条记录。
我认为它不一定是 Access DB 上的并发用户数。
我认为这是每次单击按钮时同时通过网络拉取大量数据块的人数。
网络负载/网络延迟将随着表数量、记录数量和用户数量的增长而增加。可能具有乘法效应。
当您有异地数据中心（加密）、VPN 用户（加密）、不同大陆的用户等时，请将此复合。
In my experience 10 concurrent users starts causing problems.
I'm sure there are examples w/ very small datasets working well w/ many users.
Access may be fine for some applications. There seems to be a lot of passion in this thread.
The key concept to understand here is that there is no server. EVERY QUERY will pull the ENTIRE table across the network.
If its a JOIN, EVERY QUERY will pull EVERY table involved across the network.
That's because the JOIN engine is located on your desktop.
It doesn't matter where the access file is. At best, it is located on the primary user's desktop machine. Everyone else has to utilize the network to access the data.
If you have a 100k table and you want id #1042, you will pull 100k * Record length worth of data across the network and then filter out everything but #1042. It can't cache, because your coworker may have changed the next record you want to look at.
I don't think its necessarily the number of concurrent users on an Access DB.
I think it's the number of people concurrently pulling sizable data chunks over the network each time they click a button.
Network load/Network latency will increase as table count grows, record counts grow,and user count grow. Possibly w/ a multiplicative effect.
Compound this when you have offsite data centers (encryption), vpn users(encryption), users on different continents, etc. etc. etc.