不断增长的访问前端：我应该担心吗？
我在互联网上读到的意见说，如果您正确设计或 MS Access FrontEnd，当您进行紧凑时它不应该缩小太多。我正在使用一个前端，压缩后通常约为 15 MB，但在我处理它时会增长到 20-25 MB！这是我应该关心的事情吗？
I've read opinions across the internet that say if you design or MS Access FrontEnd properly, it shouldn't shrink too much when you do a compact. I've got one front end I'm using that is typically around 15 MB when compacted, but grows to 20-25 MB while I'm working on it! Is this something I should be concerned about?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
开发和生产使用之间是有区别的。
在开发过程中，膨胀是可以预料到的——你在前端搅动数据页，修改表单、报告、模块等，因此会频繁丢弃数据页。这并没有什么问题。在开发过程中，您应该定期压缩，并偶尔进行反编译（不经常——我倾向于在繁重的开发过程中每天进行一次，和/或在将新前端分发到生产使用之前立即进行）。
在开发
在生产使用过程中，设计正确的前端不应过度膨胀。是的，当您提供编译和压缩的前端时，它会在使用过程中增长一些，但一段时间后，这种增长应该会达到顶峰。但你不应该担心这一点，因为前端是可以互换的。如果其中一个出现问题，只需更换一个新的即可。
人们在前端遇到膨胀的最常见原因是因为他们设计不正确，包括前端中的临时数据（例如，附加了数据然后被删除的表）。临时数据属于临时文件。我所有的应用程序都有一个tmp.mdb，它与前端一起分发并存储在与前端相同的文件夹中，所有临时数据都存储在那里。我通常从不压缩临时文件。
膨胀的其他来源可能包括：
对代码中的表单/报告进行设计更改（就膨胀而言，这与人类开发人员进行相同的更改相同）。在我看来，这几乎总是一个设计错误。
更改应用程序中保存的 QueryDef。这一问题不太重要，因为与其他类型的肿胀相比，肿胀的量相当小。然而，如果在一次训练中进行数千次，理论上就可以达到显着的水平。在运行时编辑保存的 QueryDefs 有几个很好的理由，但不是很多，所以虽然我不会称这样做是设计错误，但这将是一个危险信号，需要检查它以确保它不是错误的。无需编辑已保存的 QueryDef 即可高效完成。
There is a distinction between development and production use.
during development, bloat should be expected -- you're churning the data pages in your front end, revising forms, reports, modules, etc., so there will be frequent discarding of data pages. There is nothing wrong with this. During development, you should compact regularly, and occasionally decompile (not often -- I tend to do it maybe once a day during heavy development, and/or immediately before distributing a new front end into production use).
during production use, a properly-designed front end should not bloat much. Yes, when you supply a compiled and compacted front end, it will grow some during use, but after a while, that growth should top off. But you shouldn't be concerned about that, as front ends are fungible. If something goes wrong with one, you just replace it with a new one.
The most common reason people encounter bloat in front ends is because they design them incorrectly, including temporary data in their front end (e.g., a table that has data appended to it that is then deleted). Temp data belongs in a temp file. All of my apps have a tmp.mdb that is distributed along with the front end and stored in the same folder as the front end, and all temporary data is stored there. I generally never bother to compact temp files.
Other sources of bloat might include:
design changes to forms/reports made in code (which would be the same in terms of bloat as the human developer making the same changes). This is almost always a design error, in my opinion.
changes to saved QueryDefs in the app. This one is less significant, as the amount of bloat is quite small compared to other types of bloat. However, if this is being done thousands of times in a session, it could theoretically reach the level of significance. There are a few good reasons to edit saved QueryDefs at runtime, but not very many, so while I wouldn't call doing this a design error, it would be a red flag that it needed to be checked to make sure it's not something that can be accomplished efficiently without editing the saved QueryDef.
当您添加报告等时，我认为您不应该担心。我建议您在处理代码、表单和报告时定期进行反编译*。
* http://wiki.lessthandot.com/index.php/Decompile
As you are adding reports and so on, I do not think you should be concerned. I suggest that you decompile* fairly regularly when you are working on code, forms and reports.
* http://wiki.lessthandot.com/index.php/Decompile
不断增长的前端？虽然说起来很愚蠢，但确实有效。我的数据库被多家公司使用（通过云），因此应用程序几乎无法关闭以进行压缩（最后一个离开的数据库熄灭：压缩数据库）。我的客户需要始终在数据库中在线。在不到一周的时间里，前端从 16Mb 增长到超过 2Gb！这把我吓坏了。
解决方案：在文件资源管理器中，只需右键单击前端数据库，单击“属性”并选中“只读”框。
Access 将尝试写入放大的前端，但不会因只读标志而崩溃。再说一遍：简单就是真实！
谨致问候，Jaap Schokker，miniPLEX BV，瓦赫宁根，荷兰
Growing Front-End? To stupid to be true but it works. My database is used (through the cloud) by several companies and therefore the application can hardly ever be closed for compression (The last one to leave puts the lights out: compresses the database). My customers need to be online in the database all of the time. In less than one week the front-end used to grow from 16Mb to over 2Gb! This was scaring the hell out of me.
Solution: In the file explorer, simply right-click the front-end database, click 'properties' and check the 'read-only'-box.
Access will try to write the enlarged front-end but does not crash on the read-only flag. Again: just to simple to be true!
Best regards, Jaap Schokker, miniPLEX B.V., Wageningen, Holland