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 回答