我有一个产品设计为使用 MS Access 文件作为数据库的桌面产品。
现在，一些用户需要将它安装在几台 PC（比如说 2 或 3 台）上并共享数据库。
我想将 MS Access 文件放在共享文件夹中并从 PC 访问它，但是...... JET 引擎是为多用户访问而设计的？
有什么提示或事情要注意这样做吗？
编辑：该应用程序是一个 .net 应用程序，使用数据库作为存储（不使用数据库作为前端）
问问题
12596 次
13 回答
26
这个帖子的答案中有太多错误信息，我不知道从哪里开始。我刚刚花了 4 分的信誉投票否决了带有误导性和错误信息的答案。
Jet 数据库引擎（这就是这里所涉及的所有内容，正如 OP 通过编辑澄清的那样）默认情况下是多用户的——它是从头开始构建的。
当网络不低于标准时，共享 Jet 数据存储非常可靠。这意味着不是 WAN 也不是无线，因为带宽必须足以让 Jet 维护 LDB 文件（用于多用户锁定），这意味着您的本地 PC 的 Jet 数据库引擎实例每秒 ping 一次（使用默认设置），并且因为 Jet 无法从断开的连接中恢复（这在无线环境中很常见）。
Access 崩溃的情况是共享前端 Access 应用程序 MDB 时（此海报不是这种情况）。它失败的原因是因为您正在共享无法可靠共享且没有理由共享的内容。由于 Access 对象存储在 MDB 文件中的方式（整个 Access 项目存储在其中一个系统表的一条记录中的单个 BLOB 字段中），如果多个用户打开它很容易损坏。据我估计，在一个 MDB 中共享一个 Access 前端（或一个未拆分的 MDB 与表和表单/报告/等全部在一个 MDB 中）是 Access/Jet 文件损坏的 99.99% 的来源。
我对 OP 问题的基本回答是，是的，Jet 对于这种大小的应用程序来说将是一个很好的数据存储。但是，如果用户数量完全有可能增长到 25 人以上，那么最好从头开始使用在更高用户数量下更强大的数据库引擎。
于 2009-04-19T21:53:43.327 回答
7
这样做是完全可行的；但是您必须将数据库拆分为前端（带有表单、查询、代码）和后端（仅数据）。每个用户都必须在自己的计算机上拥有前端，并链接到共享的后端。
它会很慢，因为 Jet 会产生大量的网络流量。Microsoft 也逐渐弃用 Access 作为开发工具。例如，Access 2007 的安全模型远不如 Access 2003 复杂。
作为一名长期的 Access 开发人员，我正在逐渐远离 Access。
于 2009-04-18T18:31:09.923 回答
6
不要这样做... Jet 数据库声称能够支持多个用户，但是使用升迁向导将您的 Access 文件转换为 Sql Express 数据库非常容易。该数据库文件很容易被用户或管理员锁定，并且您的所有用户都将无法使用该数据库。
...而且Sql Express 是免费的。从那里升级到完整的 Sql Server 实例或其他商业数据库的路径很简单。
于 2009-04-18T18:22:32.080 回答
6
在可靠的本地网络上有 2 或 3 个用户应该没问题，只要您经常备份网络驱动器。
避免表中的任何位/布尔字段 - Jet 有一些令人讨厌的损坏问题，可以多次访问它们。
还要记住，Access 中的所有锁定都是乐观的：您偶尔会收到脏读。
MS Access 专为像这样的小型办公场景而设计：您可以通过最少的编程进行设置的非关键轻型办公用途。
预计数据文件会不时损坏 - 定期备份。
于 2009-04-18T18:38:06.303 回答
2
ACE/Jet 引擎是一款很棒的软件，虽然它旨在支持多用户，但实际上支持多用户并不是它的强项之一。对我来说最后一根稻草是从引擎中删除用户级安全性（ULS）的地方：我想我可以想象一个简单的数据库情况，所有用户都将拥有相同的权限（即对所有数据库对象的管理员访问权限）但 IMO 不是与 MS SQL Server 相比，可以很好地支持多个用户。
于 2009-04-20T08:23:36.387 回答
1
是的，它支持多个（即，工作组大小的小数量）用户通过网络文件共享进行访问。但是，文件共享架构根本不适合支持多个用户同时写入文件。客户端/服务器数据库系统（SQL Server 等）通常提供更好的性能、安全性和可靠性。
于 2009-04-18T18:26:45.877 回答
1
作为系统管理员，请不要将 Access 用于任何多用户。执行 Jeff Fritz 的建议并使用专为多用户访问而设计的数据库。您可能会认为您的小应用程序只会在少数人之间共享，但我向您保证，到今年年底它将拥有一百个用户和五十个新功能。如果这些都是 Access，而不是 VB/SQL Express，那么您的 Ops 人员会在一天晚上闯入您的房子并割断您的喉咙。
Access 不是客户端-服务器应用程序，在备份/恢复或任何自动化方面提供的功能很少。更不用说界面和数据库是非常紧密耦合的......所以如果你想把它变成一个网络应用程序，或者做出任何重大的改变，你的世界将充满痛苦。
于 2009-04-18T18:35:45.170 回答
1
很多通用软件工程师已经做过很多次了，我们已经看到 .mdb 在多用户情况下损坏。如果这么多经验丰富的专业 Access 开发人员能够做到这一点，正如我倾向于相信的那样，那么我们这些通才一定是做错了什么，而且对于我们这么多人逃避事情来说，事情一定是相当基本但不明显的尖叫着“再也不会！” 因此，如果您认为自己是一位经验丰富的专业 Access 开发人员（或者您知道如何找到），那就去吧。但是，如果您是寻求轻量级后端的通才或临时用户，那么我建议您寻找其他地方（SQL Server 是很好的 IMO）。
于 2009-04-20T08:43:20.537 回答
1
如果您的用户可以等待两倍的时间来获得具有一半功能的应用程序，那么请不要使用 Access。
于 2009-04-20T19:46:50.927 回答
0
Jet 没有支持多用户方案所需的复杂锁定逻辑。如果您的应用程序主要是读取和低争用，您可以使用它。
我已经看到网站支持许多用户，但我会推荐 SQL Express，除非您有令人信服的理由选择 Jet。
于 2009-04-18T18:26:43.053 回答
0
如果您使用终端服务器，则性能非常好。我们在一个 Access mdb 上有更多解决方案，最多可容纳 50 个用户。开发速度非常快，部署也很容易。
问题：
- 每个人都可以复制数据 mdb
- 没有访问权限
- 有限的商店程序
- 优化（压缩和修复）只能在不使用数据数据库的情况下进行
- 限制为 2 GB！
于 2009-11-10T21:58:38.897 回答
0
我可以从痛苦的经历告诉你 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 数据引擎 (MSDE) 或 Microsoft SQL Server。在 Microsoft Internet Information Server (IIS) 等高压力应用程序中使用 Microsoft Jet 时，您可能会遇到以下任一问题： 数据库损坏 稳定性问题，例如 IIS 崩溃或锁定 驱动程序突然故障或持续故障连接到需要重新启动 IIS 服务的有效数据库
于 2009-12-30T03:39:29.370 回答
0
只需检查数据库锁定文件（如 .ldb）是否存在。如果它在那里，则有人正在访问该文件。如果它不存在，目前没有人访问该文件，您可以继续。否则，请等待该文件 (.ldb) 不再存在。
于 2012-05-30T16:26:42.327 回答