max*_*gen 10 memory ms-access ms-access-2003
我在具有4GB RAM的双核机器上使用Access 2003,运行Windows XP(Service Pack 3)[5.1.2600]
我定期收到错误消息"没有足够的内存来执行此操作.关闭不需要的程序并再次尝试操作."
检查任务管理器表示有足够的可用内存.关闭其他开放的程序没有任何区别.
这种情况偶尔发生,并且在不同的情况下:有时在保存表单设计或VBA代码更改时,有时在多个表单打开和使用时.
如果尝试保存设计更改,并且发生此错误,则Access对象已损坏且无法恢复.
任何可能导致这种情况的建议都会受到欢迎.
MTIA
前端的VBA项目可能已损坏.您需要从头开始重建它,然后使用适当的Access编码实践:
在VBE选项中,关闭COMPILE ON DEMAND(有关原因的详细信息,请参阅Michael Kaplan关于DECOMPILE的文章).
在VBE选项中,启用REQUIRE VARIABLE DECLARATION.
在VBE中,自定义工具栏,以便可以轻松访问COMPILE按钮(它位于"调试"菜单上).我还建议添加CALL STACK按钮(来自VIEW菜单),因为它可以在中断模式下调试错误.这里的要点是尽可能简化调试和编译.
设置环境后,浏览新恢复项目中的所有模块,并将OPTION EXPLICIT添加到缺少它的每个模块的顶部.然后编译.您将很快找到无效代码的位置,您需要修复它.
从现在开始,编程时,经常编译,每隔两三行代码.我可能在编码时每天编译我的项目100次或更多次.
定期反编译您的项目并压缩并重新编译它.这将清除在常规开发过程中累积的任何碎屑.
这些实践确保非腐败项目中的代码尽可能保持干净.它无法恢复已经损坏的项目.
关于如何重建项目,我想我会采用Application.SaveAsText导出所有对象并使用Application.LoadFromText将它们导入新的空白数据库.这比简单地从现有的损坏前端导入要好,因为导入可以导入无法在SaveAsText/LoadFromText循环中生存的损坏结构.
我每天在Access中编程,使用大量代码的非平凡应用程序,包括大量独立的类模块.我在5年多的时间里没有丢失一个编码损坏的对象,那是在我还在使用A97的那一天.
翻阅了我的这个旧帖子，看到它引起了很大的兴趣之后，我想也许有必要进行更新吗？
因此，两年过去了，做了很多2007年的应用程序工作以及较旧的2003年（甚至是'97年）应用程序，我发现与2003年相比，2007年不太容易发生真正的崩溃-在那儿，Access对象定义（窗体和报告尤其是）。
我仍然忠实地遵循David-W-Fenton的建议1-6（上文），以及使用Application.SaveAsText（请参见上面Tony Toews的建议和链接）。
这些天，无论是97、2003还是2007，我都在努力，如果Access提供任何 “ 奇怪的信息 | 崩溃 | 抛出无法解释的错误 ”之类的提示，我将执行以下操作：
这并不能解决所有问题，但是确实可以减少我观察到的Access对象损坏的次数。
据我所知，表单或报告最有可能被损坏，我创建了一个新的 mdb，并且仅导入表（附加）、查询、脚本（仅一个）、模块和菜单。然后我使用 LoadFromText 通过函数导入表单和报告，然后进行通常的反编译/编译和压缩/修复等。
到目前为止，我已经好几天没有再发生过崩溃了，所以我可能会坚持使用这种恢复方法。
非常感谢大家的建议。
| 归档时间： |
|
| 查看次数： |
56909 次 |
| 最近记录： |