实际上,您是否尝试过将该应用程序从 mdb 转换为 accDB 格式?文件的大小不应以有意义的方式改变。(所以,请尝试这样的转换)。
事实上,据我所知,存储大小并没有什么不同。实际上,转换实际上与紧凑型 + 修复非常相似。由于未编译代码,整体生成的文件可能会小一些。(在此过程中将删除已编译的代码二进制部分)。
因此,作为一般规则,当使用 mdb 文件或 accDB 文件时,从 Access 2000 开始的文件大小不应在大小上有所不同。
当然,从 access 97 文件转换是另一回事。2000 年前的格式不支持国际字符集。并且 2000 年之前没有将文本数据存储为 uni-code(但使用 ASCII)。
因此,理论上从较旧的 97 格式升级到 2000 及更高版本实际上可以将您的存储需求增加两倍。这意味着保存在数据库中的每个文本字符都需要两个字符(这就是 uni-code 的工作方式)。
为了弥补这种相当大的数据存储需求增长,并且没有相应增加 2 gig 文件,然后在 Access 2000 及更高版本中引入了数据压缩技术。请勿将此压缩与紧凑 + 修复相混淆。
您可以逐列启用/禁用压缩。例如这里:
因此,不管这个问题如何,与 accDB 文件大小格式相比,您不应该看到 2003 格式文件的文件大小有任何差异。存储要求是相同的,您看到差异的唯一原因是压缩 + 修复和删除了转换期间发生的额外“垃圾”。(实际上,您可以通过执行 C+R 以及反编译然后再执行另一个 C+R 来获得相同的文件大小而无需转换)。
因此,例如,尝试将缩减大小的 mdb 转换为 accDB——您会注意到文件没有增加——事实上,如前所述,在从该 mdb 转换为 accDB 的过程中,您经常会看到大小减小。因此,这又是由于此处转换过程中的垃圾删除所致——而不是您使用 mdb 文件而不是 accDB 文件,因此不是因为使用 mdb 与 accDB。
如前所述,上述规则的唯一例外是 2000 年前格式的 mdb。它们没有 uni-code,因此文本数据理论上应该使用新格式的双倍存储。然而,随着对这些文本列的压缩技术的引入,实际上您的商店需求并没有增加——事实上,在某些情况下,与没有压缩列的 2000 年之前相比,您的商店需求可能会有所减少。这样做的原因是文本数据确实倾向于很好地压缩(压缩)。
至于使用什么文件格式?我会使用给定版本的默认文件格式。所以,在你的情况下,我建议最好使用 accDB。
Albert D. Kalalal(访问 MVP)
加拿大艾伯塔省埃德蒙顿