MDB 数据库文件已移出站点

Question 1

您没有详细说明您的申请是什么，或者您与客户的关系如何。因此，以下是我根据过去的经验（特别是一次事件）给出的反馈，并考虑到以下几点：

1) 您是一名应用程序开发人员，向客户销售产品，无论是为您自己的公司还是根据合同（您不是内部开发人员）。

2) 您的应用程序正在使用前端后面的 Access 引擎。

3) 您的客户正在为使用 MDB 文件的多用户应用程序付费，该文件现存储在多个客户端应用程序正在访问的 Windows 共享上。

4) 您的客户的 IT 部门对数据库有最低限度的熟悉，如果没有，他们很快就会明白。

5) 您的客户端唯一的问题是通过此 WAN 链路运行您的应用程序（即，带宽充足、基本可靠、大部分情况下可以稳定地用于其他应用程序。）

我是这样想的。我们有一个供应商向我们出售一种多用户产品，该产品会定期（似乎是随机的）无法更新中央服务器的数据库。我负责与供应商合作解决这个问题，因为当此问题发生时，我们有几个人感到不高兴，我们的用户几乎没有耐心听取任何借口，只能求助于纸质跟踪方法。

供应商坚持认为该应用程序在其他（类似）组织中运行良好，因此问题出在我们的网络或系统上。我们更换了系统。他们坚持在附近的房间安装一个微型交换机来帮助“隔离”流量，因为我们的网络流量过高，导致延迟问题（尽管只有他们的应用程序出现问题，但其他方面都没有明显的延迟问题迹象。）然后他们指责电源，坚持要求我们在工作站和微型交换机上安装 UPS 来调节电源。每次都会再次出现随机故障。

我们经历了开发人员坚持要修复的每一个环节，只是为了向他们表明，不，那是不是问题。问题相当明显。两分钟的 Google 搜索显示错误消息是文件锁定问题，快速剖析他们的应用程序显示它正在使用 MDB 数据库；基本上，该应用程序是 Access 引擎的前端。文件共享上的 MDB 文件根本不是为多用户访问而设计的。当有足够多的事务进行时，最终我们的两个客户端工作站会访问数据库应用程序，此时它无法正确锁定记录以进行更新，并且会出错。

我不是程序员，也不是数据库管理员，这只是我在研究中发现的，而且很多人都同意我的观点。这种情况在较新的版本中是否有所改变？我不知道。但我确实发现很多人只是说他们做错了。“当数据库中有大量客户端时，请使用专为处理多用户访问而设计的网络数据库解决方案。” Access 足以让奶奶保存她的饼干食谱。但对于同时通过网络处理 20 个需要事务完整性的用户来说，就不是那么好了。

现在，就你的情况而言……在与这家供应商打交道时，我可以说，当供应商坚持认为客户错了时，尽管有文件证明情况并非如此（网络正常、带宽正常、应用程序是唯一出现故障的地方、错误本身指向设计缺陷……），他们不会有耐心让你让他们费尽心机向你证明他们的网络足够可靠，可以应对所有情况但您的应用程序。我们的供应商最终所做的只是让自己看起来很愚蠢；在厌倦了与他们闹腾之后，我们放弃了他们，转而选择竞争对手，他们甚至拒绝承认错误可能是他们的应用程序的错误。

我们接受了他们要求我们做的每一个考验，但最终还是认为这是我们的错，是我们能力不足。无论是供应商想不管我们是否无能，告诉签署采购订单的人他们无能通常是不明智的，更不用说随口否认他们自己对该问题的发现。

其次，基于文件的数据库基本上依靠其他机制来帮助保护它在事务中的安全。真正的数据库管理员可能会在这里纠正我，但当时，据我所知，服务器上通过网络由多个客户端访问的这个数据库正在处理文件系统、抽象文件共享文件系统（Windows 共享）以及无法同时为多个用户正确锁定数据库的引擎。“真正的”数据库（MySQL、MSSQL、MongoDB 等）可以更好地处理这个问题，因为它们就是为此而设计的。Access 非常适合跟踪您的食谱和电影收藏。不要将它用于企业处理销售点或大型帮助台数据库。

为什么它可以在 LAN 内工作？如果你告诉他们（他们有一个 IT 部门，里面还有点机智），所有数据库都应该在 LAN 内才能正常工作，他们可能会怀疑你对数据库有什么经验，除非你确实知道他们正在使用相当于 Hayes 调制解调器的 POTS 线路设置 WAN，否则你会做出这样的声明。事实很可能是使用 MDB 文件不稳定且容易出错；将其保留在 LAN 中会将一些争用问题降低到似乎（通常）可以工作的阈值以下。如果他们增加使用该数据库的客户端应用程序的数量，即使在 LAN 内，你的应用程序出现的“随机问题”的数量也可能会增加，并且他们的 IT 部门每次必须重新启动某些东西或在你的应用程序出现故障时处理它时，都会悄悄地诅咒你的应用程序很糟糕。

换句话说，告诉他们必须将其放在本地服务器上，这只不过是给伤口贴上创可贴。如果是文件争用或引擎问题，他们仍然会遇到随机问题，而增加客户端数量将再次影响性能和/或减少应用程序随机故障之间的时间。

更不用说，如果他们因为内部已知的原因重组了服务器共享，但你的应用程序需要特别的，由于某种原因需要记录其他内容或以不同方式处理，您的申请将不会受到 IT 人员的青睐。如果您想与他们建立良好的关系，为什么要与他们为敌？

（此外……如果他们有一个连接办公室的 WAN，你确定远程用户永远不需要使用你的产品吗？或者他们可能会调动人员让一些远程用户使用你的应用程序？然后你会再次遇到分裂网络问题。）

最后，真正的解决方案是改用 MSSQL、MySQL 或其他能够处理适当多用户访问的“真正”数据库引擎。这将使您的应用程序更具可扩展性、更灵活和更可靠。它将使您的产品和您自己看起来更好。

一种解决方法是创建一种“代理”应用程序，该应用程序将客户端的查询序列化，处理它们，然后将响应分发给客户端计算机，从而确保从数据库的角度来看一切都似乎在本地处理。这将成为应用程序性能和扩展的瓶颈，这是一种笨拙的解决方法，最终会成为一个完全错误的解决方案，但如果您快速编写并运行，则可以将其用作问题的权宜之计，直到您可以实施正确的数据库迁移为止。如果管理员有我提到的那种智慧，他们可能会认真质疑您的数据库经验，但他们至少会知道您正在努力找到一种正确的迁移路径来获得可行的解决方案。

也许您客户端的 WAN 连接不可靠。也许存在其他问题，将数据库文件移动到本地网络系统会改善情况。也许我完全不了解您的应用程序的设计方式。但是，如果您的应用程序中的任何内容与我们的情况相似，则需要重新设计您的应用程序。如果您在数据库和应用程序之间有适当的抽象，那么替换数据库引擎应该不是一项艰巨的任务，并且应该会带来巨大的收益。他们的竞争对手基于 MS SQL Express。没有问题。我甚至不确定我们遇到问题的原始供应商是否仍在营业，尽管他们坚称他们拥有众多满意的客户，他们的产品没有任何问题。也许是他们撒谎的另一件事......

但我真的认为你问错了问题。你问的问题不应该是如何说服客户解决应用程序设计中的潜在缺陷，而应该是如何与客户和解，说服他们在你努力为他们的问题实施适当的解决方案时继续使用你的产品？这是我的经验。它是免费的。随你便吧。

Answer