Re: Query Conflict
- From: "David W. Fenton" <XXXusenet@xxxxxxxxxxxxxxxxxxx>
- Date: Sat, 29 Sep 2007 16:48:17 -0500
uBob Quintal <rquintal@xxxxxxxxxxxxx> wrote in
news:Xns99BA5EA86A7ECBQuintal@xxxxxxxxxxxxx:
In a summary query, any field in the WHERE clause also has to be
in the SELECT clause. because the where is applied after the
sum(), average() etc... and if it's in the SELECT clause it has to
be in a function like sum(), first(), etc... or in the GROUP BY
Clause
To get around this, there is a HAVING clause. which is applicable
to the records before the sum() is performed.Just change AND AND
(([Lake Worth... to HAVING AND (([Lake Worth C... and it should
work.
This is wrong.
However, I'll admit, it was something *I* didn't know until the last
cople of years. Here is some perfectly valoid SQL:
SELECT MyTable.Created, Count(MyTable.InventoryID) AS Count
FROM
MyTable
WHERE MyTable.UpdatedBy="MWB"
GROUP BY MyTable.Created;
You only need HAVING when you want to have criteria on the results
of the summary.
Until recently, I didn't know there was a WHERE option in the
dropdown list (where GroupBy and Sum and so forth are) in the QBE --
it's at the bottom of the list, and I never scrolled down there to
see it. Because of that, I'd been doing complex subqueries to get my
base recordset filtered so I could apply my summaries to the right
records, since if it's in the group by you end up with the wrong
numbers.
--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
.
- Follow-Ups:
- Re: Query Conflict
- From: Bob Quintal
- Re: Query Conflict
- References:
- Query Conflict
- From: Stan
- Re: Query Conflict
- From: Bob Quintal
- Query Conflict
- Prev by Date: Re: Database Options - Any other settings I should adjust?
- Next by Date: Re: Query Conflict
- Previous by thread: Re: Query Conflict
- Next by thread: Re: Query Conflict
- Index(es):
Relevant Pages
|