MS Access：没有足够的内存来执行此操作
我在具有 4GB RAM、运行 Windows XP (Service Pack 3) [5.1.2600] 的双核计算机上使用 Access 2003，
我会定期收到错误消息“没有足够的内存来执行此操作。关闭”不需要的程序并重试该操作。”
检查任务管理器表明有足够的可用内存。关闭其他打开的程序没有什么区别。
这种情况偶尔会发生，并且发生在不同的情况下：有时是在保存表单设计或 VBA 代码更改时，有时是在打开并使用多个表单时。
如果尝试保存设计更改，并且发生此错误，则 Access 对象已损坏且无法恢复。
任何有关可能导致此问题的原因的建议都将非常受欢迎。
MTIA
I'm using Access 2003 on a duo-core machine with 4GB of RAM, running Windows XP (Service Pack 3) [5.1.2600]
Periodically, I get an error msg "There isn't enough memory to perform this operation. Close unneeded programs and try the operation again."
A check of Task Manager indicates that there is plenty of free memory. Closing other open programs makes no difference.
This happens sporadically, and under different circumstances: sometimes whilst saving Form design or VBA code changes, sometimes when several Forms are open and in use.
If attempting to save design changes, and this error occurs, the Access objects are corrupted and can't be recovered.
Any suggestions on what might be causing this would be very welcome.
MTIA
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
您前端中的 VBA 项目可能已损坏。您需要从头开始重建它，然后使用正确的 Access 编码实践：
在 VBE 选项中，关闭“按需编译”（请参阅 Michael Kaplan 关于 DECOMPILE 的文章 了解原因的详细信息）。
在 VBE 选项中，启用“REQUIRE VARIABLE DECLARATION”。
在 VBE 中，自定义工具栏，以便可以轻松访问“编译”按钮（位于“调试”菜单上）。我还建议添加 CALL STACK 按钮（从 VIEW 菜单），因为它可以方便地在中断模式下调试错误。这里的重点是使调试和编译尽可能简单。
设置环境后，检查新恢复的项目中的所有模块，并将 OPTION EXPLICIT 添加到每个缺少它的模块的顶部。然后编译。您将很快发现哪里有无效代码，并且需要修复它。
从现在开始，编程时要经常编译，每隔两三行代码就编译一次。我在编码时每天可能会编译我的项目 100 次甚至更多。
定期反编译您的项目并压缩并重新编译它。这将清除常规开发过程中积累的任何污垢。
这些实践确保未损坏项目中的代码尽可能保持干净的状态。它对于恢复已经损坏的项目没有任何作用。
关于如何重建项目，我想我会采取极端的方式，使用 Application.SaveAsText 导出所有对象，然后使用 Application.LoadFromText 将它们导入到新的空白数据库中。这优于简单地从现有损坏的前端导入，因为导入可能会导入无法在 SaveAsText/LoadFromText 循环中生存的损坏结构。
我每天都在 Access 中编程，使用使用大量代码（包括大量独立类模块）的重要应用程序。我已经 5 年多没有因为代码损坏而丢失过任何对象了，那是在我还在使用 A97 的时候。
The VBA project in your front end is likely corrupted. You need to rebuild it from scratch and then use proper Access coding practices:
in VBE options, turn off COMPILE ON DEMAND (see Michael Kaplan's article on DECOMPILE for details of why).
in VBE options, turn on REQUIRE VARIABLE DECLARATION.
in the VBE, customize your toolbar so that the COMPILE button is easily accessible (it's on the Debug menu). I also recommend adding the CALL STACK button (from the VIEW menu), as it's handy for debugging errors in break mode. The point here is to make debugging and compiling as easy as possible.
having set up your environment, go through all the modules in your newly recovered project and add OPTION EXPLICIT to the top of every module that lacks it. Then compile. You'll quickly find out where you have invalid code and you'll need to fix it.
from now on, when programming, compile frequently, after every two or three lines of code. I probably compile my project 100 or more times a day when coding.
periodically decompile your project and compact and recompile it. This will clean out any crud that accumulates during regular development.
These practices insure that the code in a non-corrupt project stays in as clean a condition as possible. It will do nothing to recover an already corrupted project.
In regard to how to rebuild the project, I think I'd go the drastic route of exporting all the objects with Application.SaveAsText and importing them into a new blank database with Application.LoadFromText. This is superior to simply importing from your existing corrupted front end because the import can import corrupt structures that won't survive a SaveAsText/LoadFromText cycle.
I program daily in Access, working with non-trivial apps that use lots of code, including plenty of standalone class modules. I have not lost an object to code corruption in over 5 years, and that was back in the day when I was still using A97.
偶然发现我的这篇旧帖子，并看到它有相当多的兴趣，我想也许应该更新一下？
因此，两年后，我做了很多 2007 年的应用程序工作以及较旧的 2003 年（甚至 97 年）应用程序，我发现 2007 年比 2003 年更不容易发生真正令人讨厌的崩溃 - 其中 Access 对象定义（表单和报告特别是）很容易被损坏。
不过，我仍然虔诚地遵循 David-W-Fenton 的建议 1-6（上文），以及 Application.SaveAsText 的使用（请参阅 Tony Toews 的建议和上面的链接）。
如今，无论是我正在处理的 97 年、2003 年还是 2007 年，如果 Access 给出任何提示“很奇怪 | 崩溃 | < em>抛出莫名其妙的错误”等，我执行以下操作：
这并不能解决所有问题，但据我观察，它确实显着减少了 Access 对象的损坏数量。
Having tripped across this old post of mine, and seeing it's had a fair bit of interest, I thought maybe an update would be in order?
So 2 years down the track, doing a lot of 2007 app work as well as older 2003 (and even '97) apps, I'm finding that 2007 is less prone to really nasty crashes than 2003 - where Access object definitions (forms and reports esp.) would be easily corrupted.
I still follow the suggestions 1-6 (above) by David-W-Fenton religiously though, plus the use of Application.SaveAsText (see Tony Toews' suggestion and link above).
These days, whether it's 97, 2003 or 2007 I'm working on, if Access gives any hint of "being weird | crashing | throwing inexplicable errors" etc, I do the following:
This doesn't solve everything, but it does significantly reduce the number of corruptions of Access objects from what I'm able to observe.
天哪。
我在一家商店工作了很多年，他们选择使用 Access 作为平台。该应用程序最终变得如此之大，以至于开始达到 Access 2003 的内部内存限制。他们开始遇到与您所遇到的完全相同的问题。正如您所注意到的，发生这种情况时没有任何外部迹象表明存在内存问题。
该公司与微软详细讨论了这个问题，我相信微软最终向他们提供了补丁。因此，如果听起来与您遇到的情况类似，您可能想与 Microsoft 讨论此事，因为他们可能会为您提供相同的补丁。
最终的长期解决方案是将应用程序分成更小的部分。迁移到 Access 2007 并没有帮助；事实上，这让事情变得更糟，因为 Access 2007 有更多的活动部件。
Oh my.
I worked in a shop for many years that used Access as their platform of choice. The application eventually got so large that it began hitting an internal memory limitation of Access 2003. They began experiencing the exact same problem that you are having. As you have noticed, there is no external indication of memory problems when this happens.
The company talked at length with Microsoft about the problem, and I believe Microsoft eventually supplied them with a patch. So you might want to talk to Microsoft about this, if it sounds like a similar situation to what you are experiencing, as they may be able to supply you with the same patch.
Ultimately the long-term solution is to break the application into smaller pieces. Moving to Access 2007 didn't help; in fact, it made things worse because Access 2007 has more moving parts.
快速解决；保证工作：
打开 VBA (
Alt-F11)在立即窗口中输入以下内容：
然后
就这样了:)希望这对其他人有帮助！
Quick solution; guaranteed to work:
Open VBA (
Alt-F11)In the immediate window enter the following:
then
That's it :) Hope this helps others!
当 Access 不知道实际问题是什么时，这也是默认错误消息。现在，如果您的 MDB 特别大，例如超过 800 个带有模块的表单和报告，那么，是的，MDB 可能太大，尽管这在您创建 MDE 时给了您一条消息。 ACC2000：“Microsoft Access 无法创建 MDE 数据库”错误消息
我遇到过这种情况偶尔我自己。我当前的 MDB 还没有那么大。请注意，压缩和修复不会检测除表、索引或关系之外的对象中的错误。因此导入到另一个 MDB 是纠正这些错误的唯一方法。
您是否通过网络处理此 MDB？这是我能想到的唯一可能导致此问题的事情。
This is also the default error message when Access has no idea what the problem actually is. Now if your MDB is particularly large, say more than 800 forms and reports with modules then, yes the MDB could be too large although that gave you a message when you went to create MDEs. ACC2000: "Microsoft Access Was Unable to Create an MDE Database" Error Message
I have had this happen occasionally myself. And my current MDBs aren't quite that large. Note that compact and repair doesn't detect errors in objects other than tables, indexes or relationships. So importing into another MDB is the only way to correct these errors.
Are you working on this MDB over the network? That's about the only thing I can think of that might cause this problem.
据我所知，表单或报告最有可能被损坏，我创建了一个新的 mdb，并且仅导入表（附加）、查询、脚本（仅一个）、模块和菜单。然后我使用 LoadFromText 通过函数导入表单和报告，然后进行通常的反编译/编译和压缩/修复等。
到目前为止，触木头，我已经有几天没有再发生崩溃了，所以我可能会坚持下去用这种恢复方法。
非常感谢大家的建议。
As I know that it's either forms or reports that most likely get corrupted, I created a new mdb, and only imported tables (attached), queries, scripts (one only), modules and menus. Then I used LoadFromText to import Forms and Reports via a function, and then did the usual decompile/compile and compact/repair etc.
So far, touch wood, I haven't had another crash in some days, so I'll probably stick with this recovery method.
Many thanks to all for your suggestions.
我多次遇到这个问题，最后找到了有效的解决方案。我不知道是什么原因导致了这个问题，但我知道如何解决它。
通常，当您打开表单时会发生该错误。您需要做的就是完全重新创建该表单。最简单的方法是首先使用未记录的函数 Application.SaveAsText 将表单导出到文本文件。然后，从数据库中删除该表单并使用 Application.LoadFromText 重新加载它。
I have encountered this problem many times and finally found a solution that worked. I don't know what causes the problem, but I do know how to solve it.
Usually the error occurs when you open a form. What you need to do is completely re-create that form. The easiest way to do so is to first export the form to a text file with the undocumented function Application.SaveAsText. Then you delete the form from your database and re-load it with Application.LoadFromText.