MS Access（JET）是否适合多用户访问？

Question

我的产品设计为使用MS Access文件作为数据库的桌面产品。

现在，有些用户需要将它安装在几台PC上（假设是2或3）并分享数据库。

我想将MS Access文件放在共享文件夹中并从PC访问它，但是...... JET引擎是为多用户访问而设计的？

有任何提示或事情要注意这样做吗？

编辑： 该应用程序是一个.net，使用数据库作为存储（不使用数据库作为前端）

Answer 1

在这个帖子的答案中有很多错误的信息，我不知道从哪里开始。我只是花了4分的声誉，在答案中用误导性的错误信息投票。

1. Jet数据库引擎（这是所有涉及的，因为OP通过编辑澄清）默认是多用户 - 它是从头开始构建的。

当网络不合格时，

2. 共享Jet数据存储非常可靠。这意味着不是WAN而不是无线，因为带宽必须足以让Jet维护LDB文件（用于多用户锁定），这意味着您的本地PC的Jet数据库引擎实例每秒一次ping（带有默认设置），因为Jet无法从断开的连接中恢复（这在无线环境中很常见）。

3. Access下降的情况是共享前端Access应用程序MDB时（此海报不是这种情况）。失败的原因是因为您正在共享无法可靠共享且无理由共享的内容。由于Access对象存储在MDB文件中的方式（整个Access项目存储在一个系统表中的一个记录中的单个BLOB字段中），如果多个用户打开它，它很容易被破坏。根据我的估计，共享一个Access前端（或者一个MDB中的表和表单/报表/等所有未分离的MDB）是99.99％的Access / Jet文件损坏的来源。

我对OP问题的基本答案是，是的，Jet对于那么大的应用程序来说是一个很棒的数据存储。但是，如果用户群体有可能增长到25以上，那么最好从头开始使用在更高用户群体中更强大的数据库引擎。

Answer 2

这样做是完全可行的;但你必须将数据库拆分为前端（包括表单，查询，代码）和后端（仅限数据）。每个用户必须将前端放在自己的计算机上，并链接到共享后端。

由于Jet会产生大量网络流量，因此速度会很慢。微软也逐渐将Access作为开发工具弃用。例如，Access 2007的安全模型远不如Access 2003。

长期以来，Access开发人员逐渐远离Access。

Answer 3

不要这样做...... Jet数据库声称能够支持多个用户，但使用升迁向导将Access文件转换为Sql Express数据库非常容易。该数据库文件可能很容易被用户或管理员锁定，并且您的所有用户都无法使用该数据库。

......和Sql Express is free。从那里到Sql Server或其他商业数据库的完整实例的升级路径很简单。

Answer 4

在可靠的本地网络上有2或3个用户，只要您经常备份网络驱动器就可以了。

避免表中的任何位/ bool字段 - Jet有一些令人讨厌的腐败问题，可以多次访问它们。

还要记住，Access中的所有锁定都是乐观的：偶尔会出现脏读。

MS Access适用于这样的小型办公场景：非关键的轻型办公室使用，您可以使用最少的编程设置。

预计数据文件会不时被破坏 - 定期备份。

Answer 5

ACE / Jet引擎是一个很棒的软件，但是，虽然设计来支持多个用户，但实际上在实践中支持多个用户并不是它的优点之一。对我来说，最后一根稻草是从引擎中移除用户级安全性（ULS）的地方：我想我可以想象一个简单的数据库情况，其中所有用户都具有相同的权限（即管理员访问所有数据库但是，与MS SQL Server相比，IMO并不能很好地支持多个用户。

Answer 6

是的，它支持通过网络文件共享访问多个（即，小型，工作组大小，数量）用户。但是，文件共享体系结构对于支持多个用户同时写入文件并不理想。客户端/服务器数据库系统（SQL Server等）通常提供更好的性能，安全性和可靠性。

Answer 7

作为系统管理员，请不要将Access用于任何多用户。执行Jeff Fritz建议并使用专为多用户访问而设计的数据库。您可能认为您的小应用程序只会在少数人之间共享，但我向您保证，到年底它将拥有一百个用户和五十个新功能。如果这些都是Access，而不是VB / SQL Express，那么你的Ops人会在一天晚上闯进你的房子并割开你的喉咙。

Access不是客户端 - 服务器应用程序，并且提供的备份/恢复或任何自动化方式都很少。更不用说界面和数据库紧密耦合...所以如果你想把它变成一个网络应用程序，或做出任何重大改变，你的世界将充满痛苦。

Answer 8

许多通用软件工程师已经多次这样做了，我们看到.mdb在多用户情况下会损坏。如果有这么多经验丰富的专业Access开发人员能够做到正确，正如我倾向于相信的那样，那么我们通才必须做错事，而且对于我们这么多人来说，逃避事情的事情必须是相当基本但不明显的尖叫'再也不会！'因此，如果您认为自己是一位经验丰富的专业Access开发人员（或者您知道如何找到它），那就去吧。但如果你是一个寻找轻量级后端的通才或临时用户，那么我建议你去其他地方看看（SQL Server是一个很好的IMO）。

Answer 9

如果您的用户可以等待具有一半所需功能的应用程序的两倍，那么请不要使用Access。

Answer 10

Jet没有支持多用户场景所需的复杂锁定逻辑。如果您的应用程序主要是读取和低争用，您可以使用它。

我见过网站支持很多用户，但除非你有令人信服的理由选择Jet，否则我会推荐SQL Express。

Answer 11

如果使用终端服务器，性能真的很好。我们在一个Access mdb上有多达50个用户的解决方案。开发速度快，部署简单。

问题：

• 每个人都可以复制数据mdb
• 无访问权限
• 有限的商店程序
• 仅在没有使用数据的情况下优化（压缩和修复）数据库
• 限制为2 GB！

Answer 12

我可以从痛苦的经历告诉你Jet 3 / 3.5不可靠。我看到它在轻负载下经常崩溃，当发生崩溃时，你冒着数据损坏的风险。它过去对任何电源问题都非常敏感，任何客户端都会崩溃（甚至连接到mdb的UI），以及任何LAN问题。更新版本的Jet可能会更好，但切换到Sql Server显然是我认为除了少数用户的简单数据输入以外的任何其他方式。 Sql Express是免费的，你并没有真正失去任何东西，特别是如果你的UI是.Net而不是Access。

编辑：微软认为你不应该依赖Jet 4。

来自：http://support.microsoft.com/kb/303528

Microsoft Jet不适用于高压力服务器应用程序，高并发服务器应用程序，也不适用于每周7天，每天24小时的服务器应用程序。这包括服务器应用程序，例如Web应用程序，商务应用程序，事务应用程序和消息服务器应用程序。对于这些类型的应用程序，最佳解决方案是切换到真正的基于客户端/服务器的数据库系统，例如Microsoft Data Engine（MSDE）或Microsoft SQL Server。在Microsoft Internet Information Server（IIS）等高压力应用程序中使用Microsoft Jet时，您可能会遇到以下任何一个问题： 数据库损坏 稳定性问题，例如IIS崩溃或锁定 驱动程序突然失败或持续失败，无法连接到需要重新启动IIS服务的有效数据库

Answer 13

只检查db锁文件（如.ldb）是否存在。如果它在那里，有人正在访问该文件。如果不存在，目前没有人访问该文件，您可以继续。否则，请等待该文件（.ldb）不再存在。