Question

我目前是一名数据转换专家，我们正尝试从Access 97升级到Access2016。到目前为止，我们已经取得了成功，但是现在我遇到了一个查询，其中有超过500,000个条目。我试图将此查询追加到FoxPro表，并且出现此错误“超出系统资源”。我通过ODBC驱动程序和我创建的Advantage Streamline SQL数据源链接到现有表。我知道Access确实有2GB的限制。我要附加的查询并不复杂，但是很长。数据库和表位于我们保存所有数据的服务器上。我尝试过的一些解决方案是：

将OLE / DDE超时量更改为最大（999999999）秒：最初，这似乎在查询继续运行时起作用，但随后又出现另一个错误，指出我的条件不匹配，因此 2：我检查是否为空，并为每个字段使用NZ（）函数包装我的SELECT字段。

此后，我又得到系统资源超出错误。

好处是，旧版本的Access（97）可以很好地工作并完成工作，但是要慢慢完成。运行这些大型查询大约需要5到8个小时。

还有另一种方法可以解决此错误吗？

以下是我的SQL语句的摘要，如果它有助于解决此问题：

SELECT IIf(IsNull([GADATE]),Nz([GADATE]),DatePart("yyyy",[GADATE])) AS 
FISYRToUse
FROM AGLDET;

大约有36列与该列相似，我试图将其添加到此表中，并具有超过500,000行。

再次，谢谢。如果有什么方法可以改善我的问题，请告诉我

Answer 1

尝试：

SELECT Nz(Year([GADATE])) AS FISYRToUse
FROM AGLDET;

或：

SELECT IIf([GADATE] Is Null, "", Year([GADATE])) AS FISYRToUse
FROM AGLDET;

用于测试：

SELECT Year([GADATE]) AS FISYRToUse
FROM AGLDET
WHERE [GADATE] Is Null;

SELECT Year([GADATE]) AS FISYRToUse
FROM AGLDET
WHERE [GADATE] Is Not Null;

Answer 2

我会将数据+查询发送到临时外部accDB。然后尝试将其导出到FoxPro数据库。

这将消除iff（），nz（）表达式等。

此外，您应该在这里每秒获得约100,000行。为什么花这么长时间没有意义？

虽然数据和表在服务器上，但是您也在该服务器上运行导出和程序，对吗？如果您使用连接到服务器的客户端工作站，则需要从网络管道中提取数据并进行备份-这会很慢。

每秒10万行应该与您在此处获得的数据传输速率有关。

Access 97是旧的，因此将使用较少的内存，较少的CPU并比新版本运行得更快。在过去的20年中，每个新版本的软件都会占用更多的磁盘空间，更多的内存，更多的CPU，并且运行速度会变慢-因此，这些信息对您而言并不是新知识。

此外，如果可以的话，请尝试使用MSI版本的Access代替CTR版本。这样做的原因是office / Access的CTR版本是app-v（虚拟应用程序），并且它们往往不会释放内存和资源，更糟糕的是它们会使用更多的内存和资源。

另一个想法是将数据导出为FoxPro / dbase格式，但导出到外部文件，然后使用FoxPro或其他应用程序导入+追加。

因此，这里发生了几件事情，这个非常缓慢的过程表明这里有些大细节被遗漏了。如果您通过网络工作或整理数据，那肯定可以解释这个缓慢的问题。

但是，Access 97在这里应该并且将是相当快的最快速度。像我使用的每个软件系统一样，下一版本速度较慢，占用更多内存，更多CPU和更多资源。因此，Word，Excel或Access的下一个版本或“无论如何”运行总是较慢，并占用更多资源。

因此，您不会在以后使用较新的版本来加快速度。当然，在Access 97之后，Office就支持uni-code（对性能的影响很大）。

因此，使用较新版本总是会比较慢-在过去25年中无法想到任何例外。

因此，我将数据导出到accDB文件，然后您的NEXT导出将不具有这些条件（编辑：我的意思是使内存系统负担沉重的表达式）。这样可以很好地解决内存泄漏问题。但是，如前所述，如果可以，请使用非CTR版本的Access。（而且很难找到/找到2016版）。

附加查询Access 2016

2 个答案: