MS Access (JET) 是否适合多用户访问？

StackOverflow https://stackoverflow.com/questions/763888

  •  11-09-2019
  •  | 
  •  

题

我有一个产品设计为桌面产品，使用 MS Access 文件作为数据库。

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

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

这样做有什么提示或注意事项吗？

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

有帮助吗？

解决方案

这个帖子的答案中有太多错误信息，我不知道从哪里开始。我刚刚在声誉上花费了 4 分，否决了包含误导性和错误信息的答案。

  1. Jet 数据库引擎（这就是这里涉及的所有内容，正如OP通过编辑澄清的那样）默认是多用户的——它是从头开始构建的。

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

  3. Access 崩溃的情况是共享前端 Access 应用程序 MDB 时（本张贴者的情况并非如此）。它失败的原因是因为您正在共享无法可靠共享且没有理由共享的内容。由于 Access 对象存储在 MDB 文件中的方式（整个 Access 项目存储在系统表之一的一条记录的单个 BLOB 字段中），如果多个用户打开它，它很容易损坏。据我估计，共享一个 Access 前端（或一个带有表格和表单/报告等的未分割的 MDB）。all in one MDB）是 99.99% Access/Jet 文件损坏的根源。

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

其他提示

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

作为射流产生一吨的网络流量的这将是缓慢的。微软也正在逐步弃用Access作为开发工具。 Access 2007中，例如，具有比Access 2003中一种较复杂的安全模型。

由于长时间访问显影剂我逐渐远离接入移动。

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

...和的SQL Express是免费的。从那里到SQL Server或其他一些商业数据库的完整实例升级路径是简单的。

使用2级或3的用户的可靠的本地网络上你要细，只要背面的网络往往抬高。

避免任何位/布尔字段的表 - 喷气机与多址一些讨厌的腐败问题，他们

此外，还要在访问所有锁定承担乐观：你会得到脏偶尔读

MS访问被设计成用于小型办公室场景这样的：非关键光办公使用，可以设置与最低编程的

预期的数据文件，以获得现在，然后每隔损坏 - 定期备份

在ACE / Jet引擎是一个伟大的软件，但同时它的设计的支持多个用户，实际上是支持多用户在实践中并不是它的强项之一。对我来说，最后的救命稻草就是那么去除用户级安全（ULS）从发动机：我想我能想象一个简单的数据库情况下所有用户都将拥有同样的权限（即管理员访问的所有的数据库对象），但IMO相比未支持多个用户的良好，比方说，MS SQL服务器。

是，它支持的用户通过网络文件共享由多个接入（即，小的，工作组大小，数量）。然而，文件共享架构，根本就不是理想的支持同时写入多个用户的文件。客户机/服务器数据库系统（SQL Server等）通常提供更好的性能，安全性和可靠性。

作为一个系统管理员，请不要使用任何东西多用户访问。做什么杰夫·弗里茨提出并使用专为多用户访问的数据库。你可能会认为你的小应用程序只会被少数人之间共享，但我向你保证，它会在今年年底有几百个用户五十的新功能。如果这些都是访问，而不是VB / SQL Express，因此您行动的人会闯入你的房子一个晚上，割断你的喉咙。

Access不是客户端 - 服务器应用程序，并在备份/恢复，或不得以任何自动化的方式提供了非常少的。且不说接口和DB非常紧密耦合的...所以如果你想变成一个Web应用程序，或作出任何重大变化，你的世界将充满痛苦。

它已经这么多的通用软件工程师，我们已经看到的.mdb去腐败在多用户情况下做了很多次。如果这么多经验丰富的专家访问开发者可以得到它的权利，因为我倾向于相信，那么我们通才一定是做错了什么，并说一定是出了这么多，我们的相当基本的但无明显要逃避的事情远尖叫“下不为例！”所以，如果你认为自己是一个经验丰富的专家访问开发者（或者你知道如何找到一个），然后去了。但如果你是一个通才或临时用户寻找一个轻量级后端那么我建议你看看其他地方（SQL Server是不错IMO）。

如果您的用户可以与他们想要的功能，半长一倍等待一个应用程序，那么就不要使用访问。

Jet不具有支持多用户的情况所需要的复杂的锁定逻辑。你可以摆脱使用它，如果你的应用程序主要是读取和低竞争。

我见过的网站支持很多用户，但我会建议SQL Express的，除非你有一个令人信服的理由来选择飞机。

我可以从痛苦的经历告诉大家，喷流3 / 3.5的不可靠。我看到它经常死机轻负载条件下，当有崩溃您冒险数据损坏。它曾经是任何电源问题，任何客户端崩溃反对（甚至连接到MDB用户界面），以及任何LAN问题极为敏感。最近的Jet版本可能会更好，但切换到SQL Server显然是在我看来去比一小部分用户的琐碎数据输入的任何其他的方式。 SQL Express的是免费的，你真的不失去任何东西，特别是如果你的UI是在.NET中，而不是访问。

编辑：微软并不认为你应该靠喷气4任

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

微软的Jet不能用于高应力服务器应用程序，高并发服务器应用程序，或每天24小时，每周七天服务器应用。这包括服务器应用程序，如Web应用程序，电子商务应用，事务性应用程序和消息服务器应用程序。对于这些类型的应用程序，最好的解决办法是切换到真正的客户端/基于服务器的数据库系统，如Microsoft数据引擎（MSDE）或Microsoft SQL Server。当您在高强度应用程序，如Microsoft Internet信息服务器（IIS）使用的Microsoft Jet，您可能会遇到以下问题之一： 数据库损坏 稳定性问题，如IIS崩溃或锁定 突然发生故障或驾驶员的一直未能连接到需要重新启动IIS服务

一个有效的数据库

只是检查分贝锁定文件（如.LDB）是否有或没有。如果它是存在的，有人访问该文件。如果它不存在，目前还没有一个访问该文件，你可以继续。否则，等待当该文件（的.ldb）不再存在。

如果您使用终端服务器，性能非常好。我们有更多解决方案，一个 Access mdb 最多可支持 50 个用户。开发速度非常快，部署也很容易。

问题：

  • 每个人都可以复制数据mdb
  • 无访问权限
  • 有限的商店程序
  • 优化（压缩和修复）只能在不使用数据数据库的情况下进行
  • 限制为 2 GB！
许可以下： CC-BY-SA 和 归因
不隶属于 StackOverflow
scroll top