Functionality

[Andrew Clark]

Hello,

Can I create a column in a database that will act as a function for that
record? Say I have 3 values and I want to add them when I enter them and
store that value in a 4th column. In Excel, I would do this

A B C D
=SUM(A1:C1)
=SUM(A2:C2)
=SUM(A3:C3)

and so on.

Is there any provision for this in Access?

Thanks,
Andrew

 

[Bill Edwards]

You should not be storing calculated values in a table. Access is not Excel
and should not be used as a spreadsheet.

Create a query to view your data:
SELECT fielda, fieldb, fieldc, fielda + fieldb + fieldc AS SumOfThreeFields
FROM tblWhatever;

 

[Joseph Meehan]

Hello,

Can I create a column in a database that will act as a function for
that record? Say I have 3 values and I want to add them when I enter
them and store that value in a 4th column. In Excel, I would do this
....

Is there any provision for this in Access?

Thanks,
Andrew

You could, but it would not make any sense. You don't store computed
results in a Database normally (unless you need to store it because the
fields that it was based on are going to change and you don't want the
result to change.

BTW I believe you will find that Excel does not store the results
either. I believe Excel is only displaying the results of the calculation
that is stored.

To do what you want would require entering the information in a form or
using a query then using an update query. You don't really want to do that.

 

[onedaywhen]

don't s­tore computed
results in a Database normally (unless you need to store it ­because the
fields that it was based on are going to change and you don'­t want the
result to change.

As anyone who has ever denormalized knows, you sometimes have to
compromise design principles for practical reasons. Take a look at this
article:

http://www.dbazine.com/celko4.html

"when the cost of the calculation is higher than the cost of a simple
read. In particular, data warehouses love to have this type of data in
them to save time."

Jamie.

--

 

[Joseph Meehan]

As anyone who has ever denormalized knows, you sometimes have to
compromise design principles for practical reasons. Take a look at
this article:

I agree that is why I used the word "normally." However almost all
situations do call for normalizing and not storing computed values.

http://www.dbazine.com/celko4.html

"when the cost of the calculation is higher than the cost of a simple
read. In particular, data warehouses love to have this type of data in
them to save time."

While I agree in general I suspect you would agree that actual decision
is a little more complex.