Although your post produced an interesting discussion, I'm guessing you were
looking for an answer. I'm not an Access MVP or anything, just a regular guy,
but I would agree with fredg that you should not try to store calculations in
a table. Tables are for storing raw data. You use queries to manipulate the
data and perform calculations. I doubt the survival of the free world depends
upon your database, so if your queries aren't technically "normalized", I
think you'll be OK.

"wazabbbi" wrote:

I'm a newbee at this whole access thing. The purpose of this database is to
calculate fees and total fees collected for a project. I wanted to be able to
store the result in the same table. I was able to have the result calculated
on the form but the version I have of access is so old that I can only run
reports from a table. To further complicate things I have another field that
I want to have the total of the inspection fee and two other fields displayed
and stored. In excel its simple enough to do but I'm having trouble figuring
out how to do it in access. Eventually I'd like to run reports showing total
fees collected for a set period of time but also for a particular applicant
(our applicants may have multiple projects).

Can you guys please elaborate as to the best way for me to accomplish my
goal.

Thanks =)

"Jamie Collins" wrote:

On Aug 16, 2:16 pm, "Roger Carlson"
wrote:
I don't see why this should be contradictory. The fact is the calculated
column is not "stored" in a Query, so the cases are not even similar.

Since when did normalization have anything to do with physical
storage?! Consider that in some SQLs (e.g. Oracle) VIEWs can be
materialized i.e. their data *are* physically stored.

I repeat: normalization applies to logical tables.

By
the same reasoning, we should never store a Join of two tables because that
would produce data redundancy.

A JOIN in a query does not by necessarily result in a denormalized
structu you have to consider the whole: SELECT clause, WHERE
clause, GROUP BY clause, etc. But yes, the reasoning is the same:
reundant data in a VIEW, regardless of how it was derived, consistutes
denormalization.

Jamie.

--