只是为了澄清它实际上并不是我的数据库而且我没有选择访问权限，我只是通过开发一些已经实现的访问数据库来帮助公司。
无论如何，在他们的某些形式上，表格打开并且运行速度极慢，没有明显的原因。有一种形式需要很长时间才能在每个人的计算机上打开，但是当它存在时运行正常并且在大多数人的计算机上有另一种形式可以正常运行并且几乎无法使用。
表单上有几个子表单，后台没有运行VBA脚本，可能会导致无限循环，我很难接受想法
我已经关闭了自动名称，其中一个人说“记录集无法编辑”，因为在其中一个文本框上进行了一些分组，但即使我一直在处理它仍然运行速度很慢
答案 0 :(得分：6)
Tony Toews's Access Performance FAQ是最好的起点。
那就是说，你描述的问题听起来像是分为两类：
一个。缓慢的开放形式。
B中。表现缓慢。
A有两个常见原因：
为现有用户创建LDB文件/争用。通常使用Tony's LDB Locking article的某种形式的解决方案来解决此问题。如果打开第一个表单很慢，你可以判断这是否是问题的原因，如果你打开初始表单，打开连续表单并不慢。 FWIW，我没有使用那个方法，但是使用一个持久的数据库变量来完成同样的事情（不是最近我在SO上发布代码的时候，但也许是具有最佳上下文的那个在这里：{{3 }}）。
链接表中的过时元数据。例如，如果您在测试服务器上的前端工作，将其移动到生产环境并更新连接字符串以指向生产后端，则会发生这种情况。更新连接字符串不会刷新链接表定义中存储的所有元数据，也无法实际完全刷新它们。因此，您必须在生产环境中删除并重新创建链接表。这个问题的症状是在测试环境中立即打开或仅在一两秒内打开，并且在生产环境中需要一分钟或更长时间才能打开。打开后，他们通常工作得很好。 FWIW，我没有真正看到这个问题，除了在Access 2000的早期阶段，这是一个重大而可怕的问题，几乎让我失业（我的第一个A2000项目）。
执行速度慢的表单修复起来比较复杂，但原因通常很简单：表单一次加载太多数据。具有大量子表单（通常在选项卡控件上）和许多大型组合框的表单通常是罪魁祸首。解决方案是在实际显示之前不加载子表单/组合框。在选项卡控件中，这意味着在选项卡控件的OnChange事件中为每个选项卡加载子窗体。对于组合框，你在显示它们时加载它们，或者如果它们中有太多记录（超过1000，我会说），在用户键入1或2个字符之前不要加载行源（使用组合框的OnChange事件。）
问题在于，您正在进行一次主要的减速（在首次打开表单时加载所有内容）进行一些小得多的减速（根据需要加载每个子表单/行源）。这是一种权衡，你必须决定你想要痛苦的地方。
还有许多其他事情要做，在解决性能问题的早期阶段要检查的一件事是每个主要表单的Recordsource。左连接可以在性能方面变得非常昂贵，并且最好消除任何非绝对需要的连接。我最近刚刚加速了一个从子表左边连接到父表的表单。在子表的PK字段中，子节点不可能存在父ID，因此完全不需要左连接。删除它确实加快了从记录到记录的导航。
答案 1 :(得分：0)
从表单属性（table / query / sql语句）中识别记录源，并直接在受影响的计算机上运行它。这将有助于将问题缩小为形式或记录源。例如，您可能会发现其中一个表单引用了一个特别慢的查询（大表，多个连接，dlookup等），在这种情况下，您需要专注于优化它。
答案 2 :(得分：0)