Dear New:
I would have to say your book is wrong. Sorry. Well, perhaps it is
your interpretation of the book that is wrong. But here's the point.
Let's say you have a table with 3 rows and 2 columns to average. The
values stored are:
7 3
8 null
6 2
The answer is (7 + 8 + 6 + 3 + 2) / 5 which it 5.2 Nulls do not
affect the average. If you average the two fields separately, you get
avarages of 7 and 2.5. If you then average those you get 4.75.
That's a different, and wrong answer. The point is that the presence
of nulls will decrease the weight of the column in which they occur.
However, you may determine your own definition of average if you wish.
So, whether this is really wrong or not may depend on you. But, it is
undoubtedly a different value for average than the method I suggested.
To product the result I called "correct" you would SUM the two columns
and add together the sums. You sould also COUNT the specific columns,
which will skip counting the nulls in those columns. Add together all
the SUMs and divide that by the value formed by adding together all
the counts. That give the value the way I recommended. Using the
sample data above:
(SUM(Nz(Col1, 0)) + SUM(Nz(Col2, 0))) / (COUNT(Col1) + COUNT(Col2))
This would be (21 + 5) / (3 + 2) which is 5.2. That's how this works.
I don't believe this can be done using the AVG() function at all.
However, I still recommend a properly normalized table structure that
will permit you to handle this in one column, the way I first
explained it.
Note: if you do not now, and are certain you never will have nulls in
the table, then (AVG(Col1) + AVG(Col2)) / 2 would work as well, as I
expect your book intends. But, as illustrated, when there are nulls
in these columns, it will not always give the "correct" answer.
Tom Ellison
Microsoft Access MVP
Ellison Enterprises - Your One Stop IT Experts