网络访问Access数据库的最大连接数
如果我在网络位置上有 Microsoft Access 2007 数据库，则可以使用该数据库的客户端计算机数量是否有限制？客户端不会安装 Access，而是使用 Access Runtime 2007。
如果我将前端与后端分开，而不是每个人都直接通过网络直接访问文件，那么最大连接数是否会更改？
我知道这里描述的方法并不理想。我不会这样设计，但我必须支持它。要了解当前设计可以承受多少，就需要了解它可以处理多少个并发连接。任何信息表示赞赏！
If I have a Microsoft Access 2007 database on a network location, is there a limit to the number of client computers that can use the database? The client will not have Access installed and instead will be using the Access Runtime 2007.
Will the maximum number of connections be changed if I split the front end from the back end as opposed to everyone simply accessing the file directly over the network?
I am aware that the approach described here is not ideal. I would not have designed it this way, but I gotta support it. Part of knowing how much the current design can take is knowing how many concurrent connections it can handle. Any information is appreciated!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
Jet/ACE 的硬连线限制为 255 个连接。
但在现实生活中你永远无法接近这一点。
有多少用户可以同时共享您的数据取决于他们正在做什么。如果您有大量只读用户，那么与每个人都一直添加/编辑相比，您将能够支持更多的并发用户。
对于一个大部分是只读的并且有一些编辑器的应用程序，您可以很容易地获得 100 个并发用户，但是编辑用户越多，您在不费力气的情况下能够管理的用户就越少。
对我来说，实际限制在 15-25 之间。这就是我开始升级到服务器后端的过程的时刻。这并不是说您不能做得更好，只是为了支持更多的并发用户，您开始必须非常小心与数据交互的方式，并且您可能需要使用未绑定的数据编辑表单。一旦完成此操作，您就放弃了 Access 前端 75% 的优势。
至于“分裂”问题，与其说是有多少并发用户的问题，不如说是如果不分裂就根本无法工作的问题。任何具有多个用户的 Access 应用程序都需要拆分。没有例外。
这样，服务器上就有一个由所有人共享的后端数据文件，并且所有用户在其工作站上都有前端应用程序的单独副本，链接表指向存储在文件服务器上的共享后端。
至于连接，不用担心。具有 Jet/ACE 后端的 Access 应用程序更多的是用户问题，因为您将使用单个持久连接。尝试管理连接、打开和关闭它们会适得其反，因为它完全不必要地对文件共享机制造成负担。也就是说，您实际上并没有获得太多的容量，但最终却使用了大量的 CPU 周期和带宽而没有任何用处。
当然，与客户端/服务器编程实践相比，这是异端建议，但具有 Jet/ACE 后端的 Access 应用程序不是客户端/服务器，因此您不必担心这一点。
Jet/ACE has a hardwired limit of 255 connections.
But you'll never get close to that in real life.
How many users can share your data simultaneously depends on what they are doing. If you have lots of read-only users, you'll be able to support more simultaneous users than if everybody is adding/editing all the time.
For an app with mostly read-only and some editors, you could pretty easily get 100 simultaneous users, but the more editing users, the fewer you'll be able to manage without jumping through hoops.
To me, the practical limit is somewhere in the 15-25 range. That's the point at which I'd start the process of upsizing to a server back end. It's not that you can't do better than that, it's just that to support more simultaneous users than that, you start having to be very careful with how you interact with the data, and you might need to go to unbound data editing forms. Once you've done that, you've given up 75% of the advantage of an Access front end.
As to the "splitting" issue, it's not so much a matter of how many simultaneous users, it's just a matter of not working at all if you don't split. Any Access app with more than one user needs to be split. No exceptions.
That way there's one back-end data file on the server, shared by all, and all users have an individual copy of the front end application on their workstations, with linked tables pointing to the shared back end stored on the file server.
In regard to connections, don't worry about that. An Access app with a Jet/ACE back end is more an issue of users, as you'll use a single persistent connection. It's counterproductive to try to manage connections, opening and closing them, as it taxes the file sharing mechanisms entirely unnecessarily. That is, you don't really gain much of anything in capacity, but you end up using up a lot of CPU cycles and bandwidth for no useful purpose.
This is, of course, heretical advice in comparison to client/server programming practices, but an Access app with a Jet/ACE back end isn't client/server, so you shouldn't be worrying about that.
性能不是问题。问题是 Access 不喜欢将同一 MDB/ACCDB 中的表单、报表和模块共享给多个用户。这可能会导致 Access 数据库文件损坏和其他奇怪的问题。要解决这些问题意味着每个人都必须退出数据库。当用户位于数据库中时，开发人员也将无法处理这些对象。此外，我更喜欢用户获得 MDE/ACCDE，这样他们就不会想搞乱事情。
有关更多详细信息，请参阅“将应用程序拆分为前端和后端提示” 。另请参阅免费的基本使用 Auto FE Updater 实用程序，使新 FE 的分发相对轻松。该实用程序还很好地支持终端服务器/Citrix。
Performance is not the issue. The problem is Access doesn't like sharing the forms, reports and modules in the same MDB/ACCDB to multiple users. This can lead to corruptions and other bizarre problems in the Access database file. To fix these problems means everyone has to exit from the database. Also you the developer will not be able to work on those objects while the users are in the database. In addition I prefer that users get MDE/ACCDEs so they're not tempted to muck with things.
See "Splitting your app into a front end and back end Tips" for more details. Also see the free for basic use Auto FE Updater utility at to make the distribution of new FEs relatively painless.. The utility also supports Terminal Server/Citrix quite nicely.
我想http://office.microsoft。 com/en-us/access-help/access-2007-specations-HA010030739.aspx 会有一点帮助。
I guess http://office.microsoft.com/en-us/access-help/access-2007-specifications-HA010030739.aspx would help a little.
我不知道技术限制，但实际限制是大约 5 到 10 个并发用户。当然，这在很大程度上取决于使用模型，即写入了多少数据、同时读写了多少数据等等。
无论如何，我绝对建议将数据库和客户端分开，并认为这会增加系统的稳定性。
I'm not aware of a technical limit, but the practical limit is around 5 to 10 simultaneous users. Of course, this depends heavily on the usage model, meaning how much data is being written, how much simultaneous reads and writes, and so on.
I definitely recommend splitting the database and client in any case, and feel that it adds to the stability of the system.