Le rapport d'accès ne montre pas de données ou échoue avec "Cause GROUP BY multi-niveau non autorisée dans la sous-requête."

Question

J'ai deux requêtes que j'utilise pour générer un rapport, le problème est lorsque je lance le rapport, trois champs ne montrent aucune donnée du tout pour une raison quelconque.

Requête 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; 

Requête 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; 

Quand je lance le rapport de requête 2 ces 3 champs ne semble pas. N_Cette semaine, N_To Date et% dépensé. Tous n'ont pas de données. Ce ne sont pas les fonctions de l'IIF, car cela n'a pas d'importance si je les ai ou les supprime.

Des pensées? Si je me connecte directement au premier jeu d'enregistrements, cela fonctionne correctement, mais SQL envoie le message d'erreur: Cause GROUP BY à plusieurs niveaux n'est pas autorisée dans la sous-requête.

Existe-t-il un moyen de contourner ce message directement ou est-ce que quelqu'un a la moindre idée de la raison pour laquelle ces champs reviennent vides? Je suis à bout d'esprit ici!

Answer 1

Ayant été tourmenté aujourd'hui par ce que je pense être le même problème, je vais enregistrer ici les étapes qui l'ont résolu dans notre cas. La clé est de ne pas permettre à Access de prendre sa route par défaut lors de la structuration du GROUP BY interne utilisé dans Sorting And Grouping.

problème de base
Vous avez un rapport rptFoo dont RecordSource est question qryFoo.

Vous avez appliqué un tri et un regroupement à rptFoo, et c'est très bien. Mais qryFoo est un peu complexe; il contient une sous-requête.

Vous pouvez ajuster à la perfection, ajuster et réajuster l'élément de sous-requête, et tout est en bon état, au moins lorsque vous testez la requête autonome. Les problèmes commencent lorsque vous lancez votre rapport et obtenez cette erreur:

Multi-level GROUP BY clause is not allowed in a subquery

Ceci est l'un des problèmes que vous mentionnez.

Résolution Tentative 1:
Votre premier résultat si vous google l'erreur sera l'excellente Allen Browne site. Il a toute une section sur le site intitulé Surviving Subqueries. Le plus beau de ses suggestions pour ce problème particulier est la suivante:

• Créer une requête distincte qui gère la sous-requête. Utilisez cette requête comme "table" source pour la requête sur laquelle le rapport est basé. Le déplacement de la sous-requête vers la requête de niveau inférieur parfois (pas toujours) évite le problème , même si la deuxième requête est aussi simple que SELECT * FROM Query1;

Donc vous créez qryFooWrapper dont le contenu est simplement SELECT * FROM qryFoo. Vous en faites la source d'enregistrement pour rptFoo et, devinez quoi, le rapport commence le chargement sans erreurs.Malheureusement, il montre aussi simplement un champ vide au lieu des résultats de votre sous-requête d'origine. Cela ressemble au problème initial que vous mentionnez, et nous sommes apparemment dans une impasse.

Résolution Tentative 2:
laissant donc les suggestions d'Allen Browne d'un côté, ce qui est là pour essayer d'autre? Eh bien, il y a this discussion in Google Groups. La suggestion initiale ressemble à un kludge géant - ajoutez un ALLION malodorant à votre requête initiale. Ce ne peut pas être la réponse.

Mais attendez, à mi-chemin du fil vient un peu d'éclairage. Tout ce que fait UNION ALL, c'est de forcer Access à restructurer le GROUP BY interne qu'il génère dans le cadre de votre rapport. Et l'insertion d'un DISTINCT simple dans le qryFoo original fera le même travail, avec beaucoup moins de laideur.

Et, voilà, une solution. inclure un DISTINCT simple dans la requête d'origine.. Pas kludgy UNION ALL, pas horrible qryFooWrapper et aucune table temporaire malodorante.