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