在多用户环境中编程Microsoft Access后端数据库的正确方法

Question

由于数据库被破坏的趋势，有一种流行的观点认为Access是一个不可靠的后端数据库供并发使用，特别是对于20多个并发用户。

有少数意见认为Access数据库后端非常稳定和高效，前提是：

1. 您的网络没有问题，
2. 您正确编写程序。

我的问题非常具体：“正确编写程序”是什么意思？为了防止数据库被破坏，您必须遵循哪些要求？

编辑：要明确：数据库已经拆分。假设少于25个用户。我对性能考虑不感兴趣，只对数据库稳定性感兴趣。

Answer 1

如果您正在寻找需要避免的编程实践的很好的示例，列表中的第一个通常是不运行拆分数据库。第二个不是将前端放在每台计算机上。

例如上面的海报有各种各样的问题，但你可以打赌他们的失败是他们没有分割数据，或者他们没有将软件（前端）放在每台计算机上

对于不得不诉诸一些奇怪的锁定机制的人来说，这有点奇怪而且不是必需的。 Access（实际上是JET数据引擎，现在称为ACE）自Office 2000发布以来就内置了行锁定功能。

我已经在商业上部署应用程序书面访问了大约12年了。在那些年里，我发生过一次客户腐败。

请记住，在Microsoft开始推销和销售SQL服务器之前，他们为大约50个用户评估了JET数据库引擎。虽然我的客户没有问题，但在有人使用probem的10个案例中，有9个案例表明他们未能拆分数据库，或者他们没有在每台计算机上安装前端。

编码技巧或提示？您构建的任何程序设计都可以将少量记录加载到表单中，这是您设计的一个良好开端。换句话说，你永远不想只是简单地抛出附加到大表的表单而不限制要加载到表单中的记录。这可能是我在这里可以给出的头号提示。

例如，将每个人的帐号加载到即时柜员机是没有意义的，然后询问用户要使用的帐号。事实上，我问过一位80岁的祖母，如果这个想法有意义的话，甚至她都能解决这个问题。要求用户使用哪个帐户，然后只需加载一个客户就更有意义了。

以上相同的概念适用于网络上的拆分数据库。如果您向用户询问客户帐号，然后将表单打开到带有where子句的一条记录，那么即使后端有100,000条记录，表单加载时间也会接近即时，因为只有一条记录将是从客户表中拖出网络线。

还要记住，市场上有很多商业应用程序，例如使用喷射后端的简单会计（您实际上可以简单地打开具有MS访问权限的会计文件，他们重命名扩展以隐藏这一事实，但它是一个访问mdb文件。）

我的一些客户有3-5个使用耳机的用户，他们整天都在运行我的预订软件。许多人已经预订了超过40,000多名客户，在10年的时间里，他们中的任何一个都没有进行过调查。 （上面的一个腐败示例实际上是在单个用户系统上信不信由你。）

因此，由于我的访问产品的可靠性，我从未接到过一次服务电话。另一方面，这个应用程序只有160个表单，大约30,000行代码。它有大约65个高度相关和统一的表（强制执行关系，还有级联删除）。

因此，对于多用户应用程序，此处不需要特殊的编程方法，例外是可以降低带宽要求的良好设计。

在一天结束时，事实证明好的应用程序是不会将不必要的记录加载到表单中的应用程序。事实证明，当您以这种方式设计应用程序时，当您将后端部件更改为SQL服务器时，您会发现这种方法只需很少的工作就可以使您的访问前端在SQL服务器后端工作得很好。

最后一点，我认为这是全世界接近1亿接入用户的估计。 Access是迄今为止最受欢迎的桌面数据库引擎，并且大多数用户发现它们无法自由操作。

在网络上遇到操作问题的唯一人是那些没有拆分的人，而不是将前端放在每台计算机上。

Answer 2

另见Corrupt Microsoft Access MDBs FAQ这些年来我根据新闻组发布编辑并在Allen的页面之前编写。这说明我的客户多年来腐败很少，从未丢失数据，也不必从备份中恢复。

我不确定在这种情况下“正确编写你的程序”是什么意思。我已经阅读了一些帖子表明了这一点，但它更多的是实施方面。正如Albert指出的那样，您必须拆分数据库并为每个用户提供他们自己的FE MDB / MDE副本。您无法通过无线网卡访问后端MDB，因为它们太不稳定了。与WAN相同，除非WAN非常快/宽且非常稳定。然后，我们建议升级到SQL Server或使用终端服务/ Citrix。

我有几个客户整天都在运行20到25个用户进入系统。一个MDB有120个表，而另一个有160个表。一些表有超过600,000到800,000条记录。一个客户在五到七年内有4或5个腐败。我们找出了除了其中两个之外的所有原因。它们以某种方式与硬件相关。这些应用程序中至少有一个应该升级到SQL Server。然而，迪尔伯特的PHB（Pointy Haired Boss）取消了我。

Answer 3

目前唯一令人信服的答案似乎是减少网络流量，并确保您的硬件不会失败。

由于种种原因，我发现这些答案不能令人满意。

1. 网络流量位置是矛盾的。如果数据库只能处理一定数量的网络流量，那么人们需要明智的指导来衡量这一点，这样他们就可以智能地选择合适的数据库。

2. Blaming Access数据库在硬件故障时崩溃并不是一个可防御的位置。用户（正确地）声称他们的其他软件不会遇到这类问题。

访问数据库损坏不是一个想象的问题。经常建议5到20个用户是Access应用程序的实际上限的人是从经验中说的。

Answer 4

非常好的代码（包含在回滚的trasactions中）我们有一个呼叫中心，在Access 97天中一次有超过100个非常活跃的用户。 另一个与VB 5前端，Access Jet在便携式设备上的RAS（是旧的拨号日）到SQL Server 6数据库 - 250个并发用户。

使用向导将表单直接链接到表格的人员进行编辑......可能是个问题。

Answer 5

未完成的交易，例如在数据库打开时因任何原因无法正常关闭并且网络连接中断的记录集（已经看到NIC的省电功能导致损坏）是我的头号原因

Answer 6

我不相信用户数量是MS-Access Jet Engine的限制。 我的理解是Jet Engine将并发维护事务排队，以便一次应用它们（就像打印机队列一样打印打印作业）。通过ODBC连接，以及管理记录集大小的智能用户应用程序，锁定打开以进行编辑的记录，并且只维护DB连接足够长的时间来检索记录并保存记录，这对喷气引擎几乎没有压力。我把mdb文件看作表。可以想象，在一个数据库或更多数据库中可以有100个这样的数据。对这些表的SQL查询将是随机访问，并且mdb文件的命名约定允许在applciations程序中构建的SQL查询哪个表（mdb文件）可以访问。 MS-Access数据库可以是10s 100s或1000s千兆字节，并且运行顺畅。对数据进行适当的索引和规范化以避免存储冗余数据也会有所帮助。我从未遇到过MS-Access和ODBC以及驱动应用程序的Win32 Perl GUI界面的数据库崩溃或并发问题。除了表，索引以及可能的视图/查询之外，我不使用MS-Access对象。是的，我将数据库存储在专用PC上，并在每台工作站PC上安装我的应用程序软件。