MS Access (JET) 是否适合多用户访问？
我有一个产品设计为桌面产品，使用 MS Access 文件作为数据库。
现在，一些用户需要将其安装在几台 PC（假设 2 或 3 台）上并共享数据库。
我想将 MS Access 文件放在共享文件夹中并从 PC 访问它，但是...JET 引擎是为多用户访问而设计的？
这样做有什么提示或注意事项吗？
编辑： 该应用程序是一个.net应用程序，使用数据库作为存储（不使用数据库作为前端）
I have a product designed to be a desktop product using MS Access file as a DB.
Now, some users need to install it in a few PCs (let's say 2 or 3) and SHARE the database.
I thought to place the MS Access file in a shared folder and access it from the PC, but... the JET Engine is designed for multiple user access?
Any tips or things to be aware of doing this?
EDIT:
The app is a .net one, using the database as storage (not using the database as frontend)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（13）
这个帖子的答案中有太多错误信息，我不知道从哪里开始。 我刚刚在声誉上花费了 4 分，否决了包含误导性和错误信息的答案。
Jet 数据库引擎（这就是这里涉及的所有内容，正如 OP 通过编辑澄清的那样）默认情况下是多用户的——它是从头开始构建的。
当网络不合格时，共享 Jet 数据存储非常可靠。 这意味着不是 WAN 也不是无线，因为带宽必须足以让 Jet 维护 LDB 文件（用于多用户锁定），这意味着本地 PC 的 Jet 数据库引擎实例每秒执行一次 ping 操作（使用默认设置），并且因为 Jet 无法从断开的连接中恢复（这在无线环境中很常见）。
Access 崩溃的情况是共享前端 Access 应用程序 MDB 时（本海报不是这种情况）。 它失败的原因是因为您正在共享无法可靠共享且没有理由共享的内容。 由于 Access 对象存储在 MDB 文件中的方式（整个 Access 项目存储在系统表之一的一条记录的单个 BLOB 字段中），如果多个用户打开它，它很容易损坏。 据我估计，共享 Access 前端（或将表和表单/报告等全部集成在一个 MDB 中的未分割的 MDB）是 99.99% 的 Access/Jet 文件损坏的根源。
我对 OP 问题的基本回答是，是的，对于这种规模的应用程序来说，Jet 将是一个很棒的数据存储。 但是，如果用户数量有可能增长到 25 以上，那么最好从头开始使用在更高用户数量下更强大的数据库引擎。
There is so much misinformation in the answers in this thread that I don't know where to start. I just spent 4 points in reputation voting down the answers with misleading and wrong information in them.
the Jet database engine (which is all that's involved here, as the OP clarified with an edit) is by default multi-user -- it was built from the ground up to be that way.
sharing a Jet data store is very reliable when the network is not substandard. This means not a WAN and not wireless, because the bandwidth has to be sufficient for Jet to maintain the LDB file (for multi-user locking), which means a ping by your local PC's instance of the Jet database engine once per second (with default settings), and because Jet can't recover from a dropped connection (which is quite common in a wireless environment).
the situation where Access falls down is when a front-end Access application MDB is shared (which is not the case for this poster). The reason it fails is because you're sharing things that can't be reliably shared and have no reason to be shared. Because of the way Access objects are stored in an MDB file (the entire Access project is stored in a single BLOB field in one record in one of the system tables), it's very prone to corruption if multiple users open it. In my estimation, sharing an Access front end (or an unsplit MDB with the tables and forms/reports/etc. all in one MDB) is the source for 99.99% of corruptions of Access/Jet files.
My basic answer to the OP's question is that, yes, Jet would be a great data store for an app of that size. However, if there's any possibility at all for the user population to grow above 25, then it might be better to start off from scratch with a database engine that is more robust at higher user populations.
这样做是完全可行的； 但您必须将数据库分为前端（包含表单、查询、代码）和后端（仅数据）。 每个用户都必须在自己的计算机上拥有前端，链接到共享后端。
由于 Jet 会产生大量网络流量，因此速度会很慢。 Microsoft 也逐渐弃用 Access 作为开发工具。 例如，Access 2007 的安全模型远不如 Access 2003 复杂。
作为一名长期使用 Access 的开发人员，我正在逐渐放弃 Access。
It's perfectly feasible to do this; but you MUST split the database into a front end (with forms, queries, code) and a back end (data only). Every user has to have the front end on their own computer, linking to the shared back end.
It will be slow as Jet generates a ton of network traffic. Microsoft is also gradually deprecating Access as a development tool. Access 2007, for instance, has a far less sophisticated security model than Access 2003.
As a long time Access developer I am gradually moving away from Access.
不要这样做... Jet 数据库声称能够支持多个用户，但是使用升迁向导将 Access 文件转换为 Sql Express 数据库非常容易。 该数据库文件很容易被用户或管理员锁定，并且所有用户都将无法使用该数据库。
...并且Sql Express 是免费的。 从那里到 Sql Server 或其他商业数据库的完整实例的升级路径很简单。
Don't do it... the Jet database claims to be able to support multiple users, but it is incredibly easy to use the upsizing wizard to convert your Access file to a Sql Express database. That database file could EASILY become locked by a user or admin, and all of your users would be unable to use the database.
... and Sql Express is free. Your upgrade path from there to a full instance of Sql Server or some other commercial database is simple.
只要您经常备份网络驱动器，在可靠的本地网络上有 2 或 3 个用户就应该没问题。
避免表中出现任何位/布尔字段 - Jet 在多次访问它们时存在一些严重的损坏问题。
另请记住，Access 中的所有锁定都是乐观的：偶尔会出现脏读。
MS Access 专为此类小型办公场景而设计：只需最少的编程即可设置的非关键轻型办公用途。
预计数据文件会时不时地损坏 - 定期备份。
With 2 or 3 users on a reliable local network you should be fine, as long as you back the network drive up often.
Avoid any bit/bool fields in your tables - Jet has some nasty corruption issues with multiple access to them.
Also bear in mind that all locking in Access is optimistic: you will get dirty reads occasionally.
MS Access is designed for small office scenarios like this: non-critical light office use that you can set up with the minimum of programming.
Expect the data file to get corrupted every now and then - back up regularly.
ACE/Jet 引擎是一款很棒的软件，但是，虽然它设计是为了支持多个用户，但实际上在实践中支持多个用户并不是它的强项之一。 对我来说最后一根稻草是从引擎中删除用户级安全性（ULS）：我想我可以想象一个简单的数据库情况，其中所有用户都将拥有相同的权限（即对所有数据库的管理员访问权限）对象），但在我看来，与 MS SQL Server 相比，它不能很好地支持多个用户。
The ACE/Jet engine is a great piece of software but, while it was designed to support multiple users, actually supporting multiple users in practise is not one of its strong points. The last straw for me is where then removed user level security (ULS) from the engine: I suppose I can imagine a simple database situation where all users will have the same privileges (i.e. admin access to all database objects) but IMO that is not supporting multiple users well, as compared with, say, MS SQL Server.
是的，它支持多个（即少量、工作组大小的）用户通过网络文件共享进行访问。 然而，文件共享架构对于支持多个用户同时写入文件而言并不理想。 客户端/服务器数据库系统（SQL Server等）通常提供更好的性能、安全性和可靠性。
Yes, it supports access by multiple (that is, a small, workgroup-sized, number) of users over a network file share. However, the file share architecture is simply not ideal for supporting simultaneous writing to a file by multiple users. A client/server database system (SQL Server, etc.) generally provides better performance, security, and reliability.
作为系统管理员，请不要将 Access 用于任何多用户用途。 遵循 Jeff Fritz 的建议并使用专为多用户访问而设计的数据库。 您可能认为您的小应用程序只会在少数人之间共享，但我向您保证，到今年年底它将拥有一百个用户和五十个新功能。 如果这些都是 Access，而不是 VB/SQL Express，那么您的运维人员将在一天晚上闯入您的房子并割断您的喉咙。
Access 不是客户端服务器应用程序，并且几乎不提供备份/恢复或任何自动化功能。 更不用说界面和数据库是非常紧密耦合的......所以如果你想把它变成一个网络应用程序，或者做出任何重大的改变，你的世界将充满痛苦。
As a sysadmin, please don't use Access for anything multi-user. Do what Jeff Fritz suggests and use a database that is designed for multi-user access. You may think that your little app is only going to be shared between a few people, but I guarantee you that it'll have a hundred users and fifty new features by the end of the year. And if those are all Access, rather than VB/SQL Express, your Ops people will break into your house one night and slit your throat.
Access isn't a client-server app, and provides very little in the way of backup/restore, or any automation whatsoever. Not to mention the interface and the DB are very tightly coupled... so if you ever want to turn this into a web app, or make any serious changes, your world will be filled with pain.
很多通用软件工程师已经做过很多次了，我们已经看到 .mdb 在多用户情况下损坏。 如果这么多经验丰富的专业 Access 开发人员都能做对，正如我倾向于相信的那样，那么我们的多面手一定做错了什么，并且某些事情必须是相当基本但不明显的，让我们这么多人逃避它尖叫着“再也不会了！” 因此，如果您认为自己是一位经验丰富的专业 Access 开发人员（或者您知道如何找到一位），那么就去吧。 但是，如果您是一位通才或临时用户，正在寻找轻量级后端，那么我建议您看看其他地方（在我看来，SQL Server 是很好的选择）。
It's been done so many times by so many generic software engineers where we've seen a .mdb go corrupt in a multi user situation. If so many experienced specialist Access developers can get it right, as I'm inclined to believe, then we generalists must be doing something wrong and that something must be fairly fundamental yet non-obvious for so many of us to run away from the thing screaming 'Never again!' So if you consider yourself to be a experienced specialist Access developer (or you know how to find one) then go for it. But if you are a generalist or casual user looking for a lightweight back end then I suggest you look elsewhere (SQL Server is good IMO).
如果您的用户可以等待两倍的时间才能获得具有他们想要的一半功能的应用程序，那么就不要使用 Access。
If your users can wait twice as long for an application with half of the features they want, then don't use Access.
Jet 不具备支持多用户场景所需的复杂锁定逻辑。 如果您的应用程序主要是读取且争用较少，那么您可以不用使用它。
我见过网站支持许多用户，但我会推荐 SQL Express，除非您有令人信服的理由选择 Jet。
Jet does not have the sophisticated lock logic required to support multi-user scenarios. You can get away with using it if your application is mostly reads and low-contention.
I've seen websites support many users, but I would recommend SQL Express unless you have a compelling reason to choose Jet.
我可以从惨痛的经历告诉你，Jet 3/3.5 并不可靠。 我看到它在轻负载下频繁崩溃，当发生崩溃时，您将面临数据损坏的风险。 它曾经对任何电源问题、任何客户端崩溃（甚至链接到 mdb 的 UI）以及任何 LAN 问题都极其敏感。 最新版本的 Jet 可能会更好，但在我看来，除了少量用户的琐碎数据输入之外，切换到 Sql Server 显然是一种可行的方法。 Sql Express 是免费的，您不会真正失去任何东西，特别是如果您的 UI 位于 .Net 而不是 Access 中。
编辑：Microsoft 也不认为您应该依赖 Jet 4。
来自： http://support.microsoft.com/kb/303528
Microsoft Jet 不适用适用于高压力服务器应用程序、高并发服务器应用程序或每周 7 天、每天 24 小时的服务器应用程序。 这包括服务器应用程序，例如 Web 应用程序、商务应用程序、事务应用程序和消息传递服务器应用程序。 对于这些类型的应用程序，最佳解决方案是切换到真正的基于客户端/服务器的数据库系统，例如 Microsoft 数据引擎 (MSDE) 或 Microsoft SQL Server。 当您在 Microsoft Internet Information Server (IIS) 等高压力应用程序中使用 Microsoft Jet 时，您可能会遇到以下任一问题：
数据库损坏
稳定性问题，例如 IIS 崩溃或锁定
驱动程序连接到有效数据库突然失败或持续失败，需要重新启动 IIS 服务
I can tell you from painful experience that Jet 3/3.5 was not reliable. I saw it crash frequently under light load and when there were crashes you risked data corruption. It used to be extremely sensitive to any power problems, any client crashing against it (even the UI linked to the mdb), and any LAN problems. More recent versions of Jet might be better but switching to Sql Server is clearly the way to go in my opinion for anything other than trivial data entry with a small number of users. Sql Express is free and you don't really lose anything, especially if you're UI is in .Net, rather than Access.
EDIT: Microsoft doesn't think you should rely on Jet 4 either.
from: http://support.microsoft.com/kb/303528
Microsoft Jet is not intended for use with high-stress server applications, high-concurrency server applications, or 24 hours a day, seven days a week server applications. This includes server applications, such as Web applications, commerce applications, transactional applications, and messaging server applications. For these types of applications, the best solution is to switch to a true client/server-based database system, such as Microsoft Data Engine (MSDE) or Microsoft SQL Server. When you use Microsoft Jet in high-stress applications such as Microsoft Internet Information Server (IIS), you may experience any one of the following problems:
Database corruption
Stability issues, such as IIS crashing or locking up
Sudden failure or persistent failure of the driver to connect to a valid database that requires re-starting the IIS service
只需检查数据库锁定文件（如.ldb）是否存在。 如果存在，则表明有人正在访问该文件。 如果不存在，则目前没有人访问该文件，您可以继续。 否则，请等待该文件 (.ldb) 不再存在。
just check whether the db lock file (like .ldb) is there or not. If it is there, somebody is accessing that file. If it is not there, at present there is no one accessing that file and you may proceed. Otherwise, wait for when that file (.ldb) is no longer existing.
如果您使用终端服务器，性能非常好。 我们有更多解决方案，一个 Access mdb 最多可支持 50 个用户。 开发速度非常快，部署也很容易。
问题：
If you use a Terminal Server, the performance is real good. We have more solutions up to 50 Users at one Access mdb. Development is real fast and deployment easy.
Problems: