维修和紧凑型操作有什么作用.MDB？
如果这些操作没有阻止1GB + .MDB支持的VB应用程序崩溃,还有哪些其他选项？
为什么大型.MDB文件会导致应用程序崩溃？
"压缩和维修操作对MDB有什么作用？"
首先,不要担心修理.事实上,仍有命令声称要进行独立修复,这是过去的遗产.从Jet 3.51开始,该命令的行为发生了很大变化,并且自那以后一直保持这种状态.也就是说,除非Jet/ACE确定有必要,否则永远不会执行修复.当您执行紧凑型操作时,它将测试是否需要修复并在紧凑型之前执行修复.
那么,它做了什么？
压缩/修复会重写数据文件,消除任何未使用的数据页,在连续的数据页中写入表和索引,并在下次运行时标记所有已保存的QueryDef以进行重新编译.它还更新表的某些元数据,以及文件头中的其他元数据和内部结构.
所有数据库都具有某种形式的"紧凑"操作,因为它们针对性能进行了优化.磁盘空间很便宜,因此不是写入内容来有效地使用存储,而是写入第一个可用空间.因此,在Jet/ACE中,如果更新记录,则仅当新数据适合原始数据页时,才会将记录写入原始数据页.如果不是,则将原始数据页面标记为未使用,并将记录重写为全新的数据页面.因此,文件可以变为内部碎片,在整个文件中混合使用和未使用的数据页.
紧凑的组织整洁,摆脱所有松弛的空间.它还以主键顺序重写数据表(PK上的Jet/ACE集群,但这是您可以集群的唯一索引).索引也在那时被重写,因为随着时间的推移,这些索引也会随着使用而变得支离破碎.
Compact是一项操作,应该是任何Jet/ACE文件的常规维护的一部分,但您不必经常这样做.如果您经常出现明显的膨胀,那么它表明您可能通过存储/删除临时数据来误用您的后端数据库.如果您的应用程序添加记录并将其删除作为常规操作的一部分,那么您的设计问题会导致您的数据文件经常膨胀.
要修复该错误,请将临时表移动到其他独立的MDB/ACCDB,以便流失不会导致主数据文件膨胀.
在另一个不适用于此上下文的注释中,由于存储在其中的内容的性质,前端以不同的方式加载.由于这个问题是关于从VB使用的MDB/ACCDB,我不会详细介绍,但只需说压缩前端是开发过程中必需的东西,但在生产中很少使用.压缩生产前端的唯一原因是更新元数据并重新编译存储在其中的查询.