0

我读过互联网上的意见，说如果你正确设计或 MS Access FrontEnd，当你做一个紧凑的时候它不应该缩小太多。我有一个我正在使用的前端，压缩后通常约为 15 MB，但在我处理它时会增长到 20-25 MB！这是我应该关心的事情吗？

4

3 回答 3

4

开发和生产使用之间存在区别。

  1. 在开发过程中，应该会出现膨胀——您在前端搅动数据页，修改表单、报告、模块等，因此会经常丢弃数据页。这并没有错。在开发期间，您应该定期进行压缩，偶尔反编译（不经常——我倾向于在繁重的开发期间每天进行一次，和/或在将新的前端分发到生产使用之前）。

  2. 在生产使用过程中，一个设计合理的前端不应该膨胀太多。是的，当你提供一个编译和压缩的前端时，它会在使用过程中增长一些，但过了一段时间，这种增长应该会结束。但是你不应该担心这一点，因为前端是可替代的。如果其中一个出现问题，您只需更换一个新的即可。

人们遇到前端膨胀的最常见原因是因为他们设计不正确，包括前端中的临时数据（例如，附加了数据然后被删除的表）。临时数据属于临时文件。我所有的应用程序都有一个 tmp.mdb，它与前端一起分发并存储在与前端相同的文件夹中，所有临时数据都存储在那里。我通常从不费心压缩临时文件。

其他臃肿来源可能包括：

  1. 在代码中对表单/报告进行设计更改（就膨胀而言，这与人类开发人员进行相同更改时相同）。在我看来，这几乎总是一个设计错误。

  2. 更改应用中保存的 QueryDef。这个不太重要，因为与其他类型的膨胀相比，膨胀的数量非常小。但是，如果在一个会话中执行数千次，理论上它可以达到显着水平。在运行时编辑保存的 QueryDef 有几个很好的理由，但不是很多，所以虽然我不会称这样做是设计错误，但它是一个危险信号，需要检查它以确保它不是无需编辑保存的 QueryDef 即可高效完成。

于 2010-07-26T18:32:37.557 回答
2

当您添加报告等时，我认为您不应该担心。我建议您在处理代码、表单和报告时定期反编译*。

* http://wiki.lessthandot.com/index.php/反编译

于 2010-07-26T13:57:07.023 回答
-1

增长前端？愚蠢到真实，但它有效。我的数据库被几家公司使用（通过云），因此该应用程序几乎无法关闭以进行压缩（最后一个离开使灯熄灭：压缩数据库）。我的客户需要在数据库中一直在线。在不到一周的时间内，前端从 16Mb 增长到超过 2Gb！这把我吓坏了。解决方案：在文件资源管理器中，只需右键单击前端数据库，单击“属性”并选中“只读”框。Access 将尝试写入扩大的前端，但不会在只读标志上崩溃。再次：只是为了简单而真实！最好的问候，Jaap Schokker，miniPLEX BV，荷兰瓦赫宁根

于 2016-02-02T00:35:07.137 回答