Hi Bruce,
I hope that I did not offend you at all.  Since we don't know all the
data in the tables and how it relates to other tables, I was answering
the question in a way that I was sure would not have any undesired
results.

You can also get an cartesian product if you are joining fields that
are not primary keys. for example:
Table1
id    prod    Cust    Date
1    123    2    1/1/2001
2    456    2    1/1/2001
3    123    1    2/1/2001
4    123    2    2/1/2001

Table2
ID    cust    inv    amt
22    1    555    5
23    2    666    10
24    2    777    5

SELECT Table1.Cust, Sum(Table2.amt) AS SumOfamt, count(prod) as
CountOfProd
FROM Table1 INNER JOIN Table2 ON Table1.Cust = Table2.cust
GROUP BY Table1.Cust;

the invoice total for cust 2 will be 45 when it should be 15 because we
need other joins or sub queries.

SELECT aTable1.cust AS Expr1, Sum(Table2.amt) AS SumOfamt,
Count(aTable1.prod) AS CountOfprod
FROM (select cust, count(Table1.prod) as prod FROM Table1 group by
cust) AS aTable1 INNER JOIN Table2 ON aTable1.cust = Table2.cust
GROUP BY aTable1.cust;

will give us the correct numbers.

Another time derived tables can be a life saver is when you have huge
recordsets that you are joining.  Say you have two tables that have 5
million rows each.  If you can limit each with a derived table, then
join the smaller sets, you can speed up your data pull quite a bit.  5
million won't fly in access, but on some of the more robust engines I
have run into that scenario.

That being said I also may be overlooking something, and love this
forum because of all the stuff I learn from it.  :)

P