Question

我正在尝试整理一个Access数据库，该数据库可以处理许多保存在左侧的查询。特别是，我尝试尽可能将多级查询合并为一个保存的查询，并且遇到了这个问题。我不明白为什么以下查询无法正常工作，而我的google-fu让我失败了。生成的错误是“ FROM子句中的语法错误”

这里显示的实际查询不是我的确切用例，它是我能想到的最简单的查询，它可以复制我遇到的问题。

SELECT * 

FROM

( TRANSFORM Sum(Calls_Offered) AS Offered
SELECT CallDate
FROM tblCallData
GROUP BY CallDate
PIVOT Call_Type ) as QryA

ORDER BY 4 DESC;

如果我将转换查询另存为（例如）QryA，然后创建另一个查询，如下所示：

SELECT *
FROM QryA
ORDER BY 4 DESC;

然后运行正常，但是据我所知，两者之间应该没有任何实际区别吗？如果那是我需要做的，那还算公平，但是我希望避免这种情况。

Answer 1

摘要（TL; DR）：不要太努力地寻找精确的解决方案，而应该尝试重构查询，不要破坏出于“人为”原因的某些东西。

首先，请注意经验：这似乎是一个主观的，无用的答案，但是在开发复杂的业务应用程序时，我多次遇到这种问题。最后的前端具有成百上千的查询和SQL语句，作为保存的查询，VBA代码和RecordSource / RowSource属性中的SQL。

就像问题所描述的那样，在相同的子查询导致错误的情况下，保存的查询可以很好地执行。作为记录，我在TRANSFORM，UNION，UPDATE等各种方面都经历过。我什至遇到过相反的情况，在该情况下，子查询有效，但保存的查询却不同。 Vanilla SELECT查询通常不会出现这些问题，但是即使不时地对列列表或排序顺序进行简单，无害的更改也会导致语法完全正确的简单查询“崩溃”。我很熟练地重构查询，以获取相同的数据。有时更改连接类型会起作用，有时会更改列顺序，有时会保存vs子查询。遗憾的是，我几乎从来没有找到任何特定问题的原因或一致的解决方案。

其次，我建议不要让Access中的混乱变成困扰。不要通过坚持一种技术或组织架构来从中制造出人为的问题。具有讽刺意味的是，我通常发现最好将所有子查询拆分为已保存的查询（已损坏的查询除外，如上所述），这与您的意图相反。由于Access查询设计器无法处理子查询，因此我认为管理成为噩梦。但是我仍然有很多子查询似乎运行得最好。

我建议使用诸如命名约定之类的技术。通过定义自定义的导航类别和组来最大化“访问导航”窗格。除此之外，我什至依靠制作简单但有效的自定义导航表单，在其中可以将内容分组到选项卡中，等等。有很多选项，但是如果您的项目是默认列表，那么您选择的任何内容都是值得花费时间和精力进行组织的一个噩梦。祝你好运。

在MS Access中，是否有任何方法可以将转换查询用作后续查询的from子句中的子查询？

1 个答案: