Hi again. You were sort of overlooked in all of that, weren't you?

Let's rethink this a bit. The purpose of the database is to store the fees.
The calculations can be done wherever they are needed. If you want to have
a printout of records within a period of time (a month, for instance) you
can add a calculated (unbound) text box to the report footer. For its
Control Source:
=Sum([SomeField]) where SomeField is a numeric field for which you wish to
calculate the total. If you want to limit the report to a block of time, in
the report's Record Source query you can add a criteria to the ProjectDate
field (or whatever you call it):
Between [Enter start date] And [Enter end date]
What version of Access are you using? You should be able to create a query,
save it with a name, and select that named query as the report's (or form's)
Record Source.
You can use a similar technique to what I described for a report to get a
sum in a form. In a report you can group the records (by month, for
instance) and calculate the sum for each month. You can do running sums in
reports, and you can use queries to calculate totals in various ways. What
exactly do you need to do? In describing this, describe the table structure
and relationships, as well as the real world situation behind the database.

"wazabbbi" wrote in message
...
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.

--