3

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

查询一：

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 会抛出错误消息：Multi-level GROUP BY cause not allowed in subquery。

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

4

1 回答 1

5

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

基本问题
您有一个rptFooRecordSource 为 query的报告qryFoo。

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

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

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

这是你提到的问题之一。

解决方法尝试 1：
如果您使用谷歌搜索错误，您的第一个结果将是出色的Allen Browne 网站。他在网站上有一个名为Surviving Subqueries的部分。他对这个特定问题的最佳建议是这样的：

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

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

这看起来像你提到的最初的问题，我们似乎处于死胡同。

解决方案尝试 2：
因此将 Allen Browne 的建议搁置一边，还有什么可以尝试的？好吧，Google Groups 中有这个讨论。最初的建议看起来像一个巨大的杂物 - 将一个臭的 UNION ALL 附加到您的初始查询中。这不可能是答案。

但是等等，在线程的中途会有一些照明。UNION ALL 所做的就是强制 Access 重组它作为报告的一部分生成的内部 GROUP BY。并且在原始文件中插入一个简单的 DISTINCTqryFoo将做同样的工作，而且丑陋得多。

而且，瞧，一个解决方案。在原始查询中包含一个简单的 DISTINCT。. 没有 kludgy UNION ALL，没有可怕qryFooWrapper的，没有臭的临时表。

于 2011-08-12T14:01:59.937 回答