Alpha 4 to Access

[Joe70]

I imported Alpha4 to Access 2003 with no problems. Now I have a one
table with 22 fields. This is a small Auto Repair Shop database.

Created a form to input data, but the data in the calculated fields do
not enter in the table. Right now I have about 15 fields and four of
them have calculation in them which do work in the form.

When I look at the table these calculated fields are not there. Not
sure why the data is not going into the table. Everything works fine
in Alpha4.

One field name is Total =[PARTS]+[LABOR]+[TAX]
which shows correctly on the form but the same field in the table is
blank.

 

[Douglas J. Steele]

Access doesn't allow you to put calculations in tables. You must create a
query, put the calculation in the query, and use the query wherever you
would otherwise have used the table to get the same capability in Access.

 

[Joe70]

The calculation is in the form. I want the results to be entered in
the table also.

 

[Douglas J. Steele]

As fellow Access MVP John Vinson likes to say "Storing calculated data
generally accomplishes only three things: it wastes disk space, it wastes
time (a disk fetch is much slower than almost any reasonable calculation),
and it risks data validity, since once it's stored in a table either the
Total or one of the fields that goes into the total may be changed, making
the value WRONG."

My advice, still, is to use a query.

 

[Arvin Meyer [MVP]]

The only exceptions to the rule include a requirement to store the history
of the transaction, like payroll, but only if you aren't storing all the
elements of the calculation in the same row of data. I personally prefer to
store all the elements of the calculation because it gives me more
flexibility to recalculate or change the data in a scenario query.
--
Arvin Meyer, MCP, MVP
Microsoft Access
Free Access downloads
http://www.datastrat.com
http://www.mvps.org/access

 

[(PeteCresswell)]

Per Arvin Meyer [MVP]:

The only exceptions to the rule include a requirement to store the history
of the transaction, like payroll, but only if you aren't storing all the
elements of the calculation in the same row of data.

There also situations where the calculation is just too extreme to be useful
real-world.

I'm thinking about rolling rates of return - where computing rolling rates for
3, 6, 9, 12, 24, 36, 48, 60, 72, and 84 months for each return kicks the brains
out of a CPU to the extent that any report or screen that has to do same becomes
useless.

 

[Joe70]

Hmm... I'm just trying to creating a simple invoice form that will
enter the results to a table. I don't want to add the totals manually
and enter them manually. This works fine in Alpha4, but in Access I'm
having problems.
I will have to study this further... maybe I've been using Alpha4 for
too many years and dont' see how Access does the same thing. Maybe I'm
not explaining my problem correctly.

 

[Arvin Meyer [MVP]]

What we're saying is that you add what is called an alias column in an
Access query and base your report or form on the query:

Total: [Qty]*[Price]

The SQL in the query then looks something like:

Select [Qty], [Price], [Qty]*[Price] As Total From MyTable;
--
Arvin Meyer, MCP, MVP
Microsoft Access
Free Access downloads
http://www.datastrat.com
http://www.mvps.org/access