场景：有一个遗留程序（不确定是什么语言），我被要求“压缩和存档数据库中的表单”。在用户打开应用程序的那一刻，它需要大约2-5分钟来加载大约27000条记录！我的理论是，它正在加载启动时的所有记录，但这可能不是唯一的原因。在进行了一些挖掘并找到看起来正确的Access Back端之后，我还在公司内的15个以上的其他共享中找到了相同的访问文件。现在这个应用程序是在1997年左右创建的，当时我猜测Access是常态，但他们真的会从15个以上的Access数据库中获取数据吗？加速这个程序的标准似乎是将旧记录存档到另一个访问数据库中（这就是为什么我认为它在启动时加载所有内容。
问题：我周一开会讨论该计划，并想知道是否有人可以提出一些有用的问题，理论，解决方案等。这不是我不能在我的自己，我只是认为另一个观点不会受到伤害。另一个有趣的事实是，我可能或者可能无法获得源代码，因为它可能是由承包商创建的，代码很久以前就丢失了。
旁注：Access是否可以自动存档旧记录？这意味着将它们转移到另一个名为XXXArch的数据库。
提前致谢。我会尽力回答你的任何问题。
修改：
有关情况的更新。
它看起来只是使用一个数据库作为主数据库而另一个数据库存档。我仍然没有自己的用户帐户来打开应用程序，但在查看数据库时，有一个用户表，其中包含登录ID和相同的密码（PASSWORD），因此我尝试以其中一个用户身份登录，只需选择一些数据不修改任何东西。选择时我几乎可以立即获得数据，并且没有看到其他用户获得的任何减速。我还没有看到源代码，但是我可以告诉它（将exe文件放入记事本中）它看起来像是在VBA中编码而且可能是使用MS Access创建的。此外，应用程序似乎在数据文件夹中创建temp.mdb。目前它没有任何内容。没有桌子，没有。我假设/希望这是降低用户速度的原因，可以删除以提高性能。我会在获得源代码后发布另一个更新，并更好地了解减慢速度的原因。
答案 0 :(得分：5)
需要考虑的几件事情：
Access（MDB）数据库往往需要定期压缩/修复，如标题中所述，如果它们经常使用。但是我很少发现它有助于提高性能而不是最低限度。如果文件耗时很长，那么如果用户通过慢速网络连接访问文件，那么该文件可能会成为问题的一部分。
有人会建议在您的公司或此论坛中升级到像SQL服务器这样的“大”数据库。在您解决问题或除非您有其他原因而不是表现之前，请不要这样做。问题是由不良的应用程序设计或数据库架构引起的。在不改变方法的情况下在问题上投入更强大的工具不太可能有所帮助。
Access数据库在最大化数据之前很久就会对并发用户产生最大影响。很多用户（30+）刚刚开始使用该系统吗？这可能是问题的一部分。
归档旧记录：您将需要构建一些东西来执行此操作。好消息是它并不是那么难。
访问15个以上的数据库：您确定前端GUI未在Access中编写。这是一种通用架构，可以访问最终用户机器上的MDB前端（在任何地方复制），连接到网络上的中央MDB数据文件。最好的方法是打开数据库，看看它们是否只包含表格，表格+表格/报告。
答案 1 :(得分：4)
在我看来，您的首要任务是解决此问题：
我可能或者可能无法获取源代码，因为它可能是由承包商创建的，代码很久以前就丢失了。
就目前而言，你要求我们推测缓慢的原因和补救措施......不知道究竟发生了什么。
答案 2 :(得分：3)
如果您没有源代码，则无法将后端数据库更改为SQL Server，也不能将其他任何内容更改。
但是，如果您确实可以访问数据文件并且能够编辑它们，为什么不检查索引？对于包括Access在内的任何数据库来说，27K记录都是微不足道的，加载数据的速度很慢，这表明表格没有被正确编入索引。如果检查表并且在明显的字段上看不到索引，那么尝试添加它们，看看它是否加快了速度。
如果没有，那么这意味着该应用程序设计糟糕，并且由于您缺少源代码，因此您无法做很多事情。
当然，以上所有假设网络环境都适用于Access / Jet / ACE。也就是说，如果这些数据库文件是通过有线局域网以外的任何其他方式访问的，那么就无法做到这一点（广域网和WiFi完全用于Jet / ACE）。
最后，关于归档问题，我认为除非你真的遇到硬件/软件的硬限制，否则没有理由存档数据。在这种情况下，你甚至都不接近。