3

レポートを生成するために使用している 2 つのクエリがあります。問題は、レポートを実行すると、何らかの理由で 3 つのフィールドにデータがまったく表示されないことです。

クエリ 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、および % Spent。すべてデータがありません。IIF 関数ではありません。そこに IIF 関数があるかどうかは関係ありません。

何かご意見は？最初のレコードセットに直接接続すると正常に動作しますが、SQL は次のエラー メッセージをスローします。

そのメッセージを回避して直接リンクする方法はありますか、またはこれらのフィールドが空白に戻る理由を誰かが知っていますか? 私はここで機知に富んでいます！

4

1 に答える 1

5

同じ問題だと思うことに今日悩まされたので、私たちの場合にそれを解決した手順をここに記録します。重要なのは、並べ替えとグループ化で使用される内部 GROUP BY を構造化するときに、Access がデフォルト ルートを使用できないようにすることです。

基本的な問題RecordSource が query で
あるレポートがあります。rptFooqryFoo

にいくつかの並べ替えとグループ化を適用しましたが、それでrptFoo問題ありません。しかしqryFoo、少し複雑です。サブクエリが含まれています。

完璧に微調整qryFooし、そのサブクエリ要素を調整して再調整すると、少なくともクエリをスタンドアロンでテストするときは、すべて問題なく表示されます。レポートを起動して次のエラーが発生すると、問題が発生します。

複数レベルの GROUP BY 句はサブクエリでは許可されていません

これはあなたが言及した問題の1つです。

解決策の試行 1:
エラーをグーグルで検索した場合の最初の結果は、優秀なアレン ブラウンのサイトです。彼はSurviving Subqueriesというタイトルのサイト全体のセクションを持っています。この特定の問題に対する彼の提案の中で最もよく見えるのは次のとおりです。

  • サブクエリを処理する別のクエリを作成します。このクエリを、レポートの基になるクエリのソース「テーブル」として使用します。サブクエリを下位レベルのクエリに移動すると、2 番目のクエリが SELECT * FROM Query1;のように単純な場合でも、問題が回避されることがあります (常にではありません)。

したがってqryFooWrapper、コンテンツが単純に作成されますSELECT * FROM qryFoo。これをレコード ソースにするrptFooと、レポートがエラーなしで読み込まれ始めます。悲しいことに、元のサブクエリの結果ではなく、空白のフィールドが表示されるだけです。

これはあなたが言及した最初の問題のように見えます。

解決案 2:
Allen Browne の提案は脇に置いておきますが、他に何を試すことができますか? Google Groups でこのディスカッションがあります。最初の提案は巨大なクラッジのように見えます - 最初のクエリに臭い UNION ALL を追加してください。これでは答えられません。

しかし、待ってください。スレッドの途中で、いくつかのイルミネーションが表示されます。UNION ALL が行っていることは、Access がレポートの一部として生成する内部 GROUP BY を強制的に再構築することだけです。また、オリジナルに単純な DISTINCT を挿入するqryFooと、同じ作業が行われ、見苦しさが大幅に軽減されます。

そして、ほら、解決策。元のクエリに単純な DISTINCT を含めます。. ぎこちなくUNION ALL、恐ろしく、qryFooWrapper臭い一時テーブルはありません。

于 2011-08-12T14:01:59.937 に答える