访问报告不显示数据或失败并显示“子查询中不允许使用多级 GROUP BY 原因”。

Question

我有两个查询用来生成报告，问题是当我运行报告时，三个字段由于某种原因根本不显示任何数据。

查询1：

SELECT ClientSummary.Field3 AS PM, 
       ClientSummary.[Client Nickname 2] AS [Project #], 
       ClientSummary.[Client Nickname 1] AS Customer, 
       ClientSummary.[In Reference To] AS [Job Name], 
       ClientSummary.Field10 AS Contract,

      (select sum([Billable Slip Value]) 
       from Util_bydate as U1 
       where U1.[Client Nickname 2] = ClientSummary.[Client Nickname 2]) 
          AS [This Week],

      (select sum([Billable Slip Value]) 
       from Util as U2 
       where U2.[Client Nickname 2] = ClientSummary.[Client Nickname 2] ) 
          AS [To Date],

      [To Date]/[Contract] AS [% Spent],

      0 AS Backlog, 

      ClientSummary.[Total Slip Fees & Costs] AS Billed, 
      ClientSummary.Payments AS Paid, ClientSummary.[Total A/R] AS Receivable, 

      [Forms]![ReportMenu]![StartDate] AS [Start Date], 
      [Forms]![ReportMenu]![EndDate] AS [End Date]

FROM ClientSummary;

查询2：

SELECT JobManagement_Summary.pm, 
       JobManagement_Summary.[project #], 
       JobManagement_Summary.Customer, 
       JobManagement_Summary.[Job Name], 
       JobManagement_Summary.Contract, 
       IIf(IsNull([This Week]),0,[This Week]) AS [N_This Week], 
       IIf(IsNull([To Date]),0,[To Date]) AS [N_To Date], [% Spent], 
       JobManagement_Summary.Backlog, 
       JobManagement_Summary.Billed, 
       JobManagement_Summary.Paid, 
       JobManagement_Summary.Receivable, 
       JobManagement_Summary.[Start Date], 
       JobManagement_Summary.[End Date]
FROM JobManagement_Summary;

当我从查询 2 运行报告时，这 3 个字段不会出现。N_This Week、N_To Date 和 % Spend。全部都没有数据。它不是 IIF 函数，因为我是否有这些函数或删除它们并不重要。

有什么想法吗？如果我直接连接到第一个记录集，它工作正常，但 SQL 会抛出错误消息：子查询中不允许使用多级 GROUP BY 原因。

有什么方法可以绕过该消息以直接链接到它，或者有人知道为什么这些字段会返回空白吗？我在这里束手无策！

Answer 1

今天被我认为是同样的问题所折磨，我将在这里记录在我们的案例中解决该问题的步骤。关键是在构建排序和分组中使用的内部 GROUP BY 时，不要允许 Access 采用其默认路由。

\n\n

基本问题\n您有一个RecordSource 为 query 的
报表。rptFooqryFoo

\n\n

您已经对 进行了一些排序和分组rptFoo，这很好。但qryFoo有点复杂；它包含一个子查询。

\n\n

您微调qryFoo到完美，调整并重新调整其子查询元素，一切看起来都很好，至少当您独立测试查询时是这样。当您启动报告并收到以下错误时，问题就开始了：

\n\n

\n

子查询中不允许使用多级 GROUP BY 子句

\n

\n\n

这是你提到的问题之一。

\n\n

解决方法尝试 1：
\n如果您用 google 搜索该错误，您的第一个结果将是优秀的Allen Browne 网站。他在网站上有一个完整的部分，标题为“生存子查询”。他对这个特定问题的最好的建议是：

\n\n

\n
• 创建一个单独的查询来处理子查询。使用此查询作为报告所基于的查询的源“表”。有时（并非总是）将子查询移至较低级别的查询可以避免该问题，即使第二个查询与SELECT * FROM Query1 一样简单；
\n

\n\n

所以你创建qryFooWrapper的内容很简单SELECT * FROM qryFoo。您将其作为记录源rptFoo，猜猜看，报告开始加载，没有错误。遗憾的是，它也只是显示一个空白字段，而不是原始子查询的结果。

\n\n

这看起来就像你提到的最初的问题，我们似乎走进了死胡同。

\n\n

解决方案尝试 2：
\n那么，把 Allen Browne 的建议放在一边，还有什么可以尝试的呢？Google 网上论坛中有这样的讨论。最初的建议看起来像是一个巨大的拼凑 - 将一个臭味的 UNION ALL 附加到您的初始查询中。这不可能是答案。

\n\n

但是等等，线程的一半出现了一些启发。UNION ALL 所做的一切就是强制 Access 重组其生成的内部 GROUP BY 作为报告的一部分。在原始文件中插入一个简单的 DISTINCTqryFoo也可以完成相同的工作，而且丑陋程度要低得多。

\n\n

并且，瞧\xc3\xa0，一个解决方案。在原始查询中包含一个简单的 DISTINCT。。没有笨拙UNION ALL、没有可怕qryFooWrapper、没有臭味的临时桌子。

\n