2009-01-16 98 views
6

我有一个大型的MS Access应用程序,在VBA代码中有很多计算。当我运行它时,它最终会因文件大小过大而崩溃。有很多中间表和查询创建并随后删除,但Access不收回该空间。我努力关闭所有中间记录集并将所有临时对象设置为空,但没有任何帮助。我可以让代码运行的唯一方法是运行其中的一部分,停止并修复/压缩文件,然后重新启动代码。越来越多的MS Access文件大小问题

没有更好的方法吗?

谢谢

回答

0

不幸的是,MS Access有问题,当你得到过大 - 我觉得最大尺寸为2GB的访问DB。

您可以考虑迁移到SQL Express,VistaDB的,等

+0

2GB限制是有道理的,但它可能不是访问限制,但是操作系统限制。也就是说,由于访问将数据存储在单个文件中,操作系统上的2GB文件大小限制可能是故障点。 – JohnFx 2009-01-16 16:53:26

+0

我不知道有2GB文件大小限制的任何最新版本的Windows。确实,它不是* Access *限制 - 这是Jet的限制,它硬连接到Jet。 – 2009-01-16 21:51:34

+0

最近的附录:某些文件系统(如FAT32)具有2GB的文件大小限制。但是没有任何意义的人在Windows上使用FAT32 - 随着Win9x系列Windows版本的消亡而熄灭。 – 2010-04-15 20:05:09

3

你处理什么尺寸?它崩溃时的错误代码是什么?如果仅仅是因为文件变得“太大”,我会感到惊讶,但我想有一个限制。从您对所有临时工的描述中可以看出,可能会有助于改进设计。

编辑:我希望你意识到用别的东西代替数据库是不平凡的 - 即使你试图保留除表格外的其他任何内容。访问querydefs是唯一的,Access SQL是非标准的,你基本上会重新开始。

我见过的大部分Access应用程序都有很多重构的机会;如果a)你理解逻辑和业务规则,并且b)你对Access编程有深刻的理解,通常并不困难。但是对于任何替代品来说,这或多或少都是如此。如果我是你,并且你在这两个领域都有点矮,也许你可以得到一些帮助。但我会尝试首先拯救Access应用程序。

还有一个关于将表移动到一个或多个附加的MDB中的提示。总的来说,这是一个可靠的,成熟的技术。但首先我要弄清楚问题的真正原因是什么。

+0

+1我同意这听起来像设计可以改进。 – Fionnuala 2009-01-16 17:04:46

9

您应该能够在VBA代码中运行紧凑功能。

我在做访问工作时很久很久以前收到了以下代码片段。

Public Sub CompactDB() 
    CommandBars("Menu Bar").Controls("Tools").Controls("Database utilities").Controls("Compact and repair database...").accDoDefaultAction 
End Sub 

你可以把它放在你的代码中来解决它。

注意:如果您遇到这些类型的缩放问题,您可能还会考虑增大到更大的数据库系统。

0

根据http://office.microsoft.com/en-us/access/HP051868081033.aspx,Access 2003和2007有2 GB的限制。但是,将一些或所有表移动到单独的.mdb文件并将其链接到这些表中很容易。无论如何,最好有两个文件,一个用于数据,一个用于所有宏,查询等等。如果您的表文件接近2 GB的限制,您甚至可以拥有多个文件。

2

我推数据到MS SQL(永久数据和中间表);并且您可以暂时将代码部分留在MS Access中。

这解决了两大问题:

  1. 的数据自然会保持比较稳定/可靠的(我不能告诉你多少次我有一个损坏的MS Access数据库)。
  2. 您的Access数据库不会增长/变化很大(一旦所有代码已经运行和编译,它应该达到平衡)。

这两种意味着没有更多的具有压缩/修复数据库;您可以获得MS SQL的免费版本(Express Edition),这并不难。

0

如果你不希望切换到SQL Express或类似的,你可以挖以下思路:

  • 打开另一个“外部”访问数据库(MDB文件),对所有的临时表,所以你可以把所有临时数据在外部文件中,当你关闭你的应用程序时抛弃mdb文件。然后你会在你的代码操纵“currentDb”对象和其他数据库,你建立在启动时,通过飞机,OLEDB或ODBC连接连接到您的代码
  • 独立的永久表,并在需要的时候,把数据导入到本地客户端界面来构建临时表。这可以通过例如使用“DoCmd.transferDatabase acLink”将外部数据库链接到本地​​/客户端文件来完成。这也可以通过连接到永久数据通过OLEDB连接,打开所需的记录集并将它们保存为XML文件本地来完成。还有很多其他解决方案可以在这里实施。
0

事务方面的Jet文件大小的状态对我没完没了的问题。

我目前正在从Access数据库A观看一段自己的VBA代码,因为它使用ADO对Access数据库B上的表执行一系列单记录字段更新(通过数据库中的可更新查询引用一个)。单个字段是CHAR(8)。随着每4次更新,数据库B增长大约8千字节。对此没有好的借口。文件大小的增加会严重降低性能;随着每个文件的增长,更新速度从每秒约一秒(在使用单记录SQL查找的约30-40K记录的表中并且没有任何索引的任何地方)到每5-10秒一个更慢。 现在,我承认,在运行此更新代码之前,我已经精简/修复了数据库B;也许如果我没有那样做,表演就不会这么糟糕。如果更新的目标字段是,例如,键入备忘录,那么我会预料到这一点。但是对CHAR()字段进行更新并得到这个结果是不合理的。

最上面的(任何一个解决方案没有特别批评意)似乎是对于使用相对固定的业务应用程序的安排(聊到同一目标数据库中的所有的时间),应用有效的解决方案。我不是。 。 。我无法更改目标数据库(数据库B),因为它是由我们用于从其应用程序导出和导入数据的供应商工具生成和使用的。

我的理解和赞扬上述作家的未来与用户的问题的解决方案。但是,我不能让它站在软件设计/实现阻碍用户使用产品的用户期望它的功能。