Expression in forms

[Jamo]

I am new to Access and I have a Table with a field called total.I have
created a form to enter or modify data .I put an expression in the form in
the Total field .The expression adds the results of several fields in the
form and I want to add the total to the Table total field.The expression adds
the field in the form but I can't get the field in the Table to update.I am
not sure how do do this.not even sure what expression to write and where to
put it .I gues what I am looking for is a clear step by step proceedure on
how to do that. I realy need help

 

[John W. Vinson]

I am new to Access and I have a Table with a field called total.

Then you have an incorrectly structured table. The Total field should simply
*not exist*.

I have
created a form to enter or modify data .I put an expression in the form in
the Total field .The expression adds the results of several fields in the
form and I want to add the total to the Table total field.The expression adds
the field in the form but I can't get the field in the Table to update.I am
not sure how do do this.not even sure what expression to write and where to
put it .I gues what I am looking for is a clear step by step proceedure on
how to do that. I realy need help

Storing derived data such as this in your table accomplishes
three things: it wastes disk space; it wastes time (almost
any calculation will be MUCH faster than a disk fetch); and
most importantly, it risks data corruption. If one of the
underlying fields is subsequently edited, you will have data
in your table WHICH IS WRONG, and no automatic way to detect
that fact.

Just redo the calculation whenever you need it, either as a
calculated field in a Query or just as you're now doing it -
in the control source of a Form or a Report textbox.

 

[Jamo]

--
Center for technica education

Then you have an incorrectly structured table. The Total field should simply
*not exist*.


Storing derived data such as this in your table accomplishes
three things: it wastes disk space; it wastes time (almost
any calculation will be MUCH faster than a disk fetch); and
most importantly, it risks data corruption. If one of the
underlying fields is subsequently edited, you will have data
in your table WHICH IS WRONG, and no automatic way to detect
that fact.

Just redo the calculation whenever you need it, either as a
calculated field in a Query or just as you're now doing it -
in the control source of a Form or a Report textbox.

--

John W. Vinson [MVP]
.
John:

Thank you so much for the information. I will delete that field out of
the table and create a report to do the total calculation, however for my own
curosity can that be done what I was trying to do in a form? I will follow
you advice and proceed from here

 

[John W. Vinson]

Thank you so much for the information. I will delete that field out of
the table and create a report to do the total calculation, however for my own
curosity can that be done what I was trying to do in a form? I will follow
you advice and proceed from here

Well, you can't do calculations in tables - but you have at least three other
choices!

You can do a calculation in a Query by just typing the calculation expression
in a vacant Field cell:

Total: [FieldA] + [FieldB]

Or you can display a calculation on a Form by putting an expression in the
control source property of a form Textbox:

= [FieldA] + [FieldB]

The same technique works on a Report as well.

If you want to sum the value of a field across multiple records, you can also
do it three (or more) different ways: with a Totals Query; or in the Footer of
a Form or Report:

= Sum([FieldA])

So you're not losing much by being unable to do the calculation in a table.

SideNote: Access 2010 has <sigh> calculated fields in tables. In reality
they're a hidden query, and in fact this can be a useful technique, but you do
need to understand the underlying logic.

 

[Jamo]

--
Center for technica education

John's advice is spot on, of course, and should be followed in the vast
majority of cases, including the scenario you have here. In the very few
cases where storing a calculated value is necessary, you have to move the
calculation to somewhere other than the Control Source for the textbox, so
that the Control Source can be a field in the underlying table and theresults
stored in that field.

If, for instance, you were adding the values of two textboxes together,
txtFieldA and txtFieldB, you'd do something like this, in the AfterUpdate
event of each of them:

Private Sub txtFieldA_AfterUpdate()
Me.txtTotal = Nz(Me.txtFieldA, 0) + Nz(Me.txtFieldB, 0)
End Sub

Private Sub txtFieldB_AfterUpdate()
Me.txtTotal = Nz(Me.txtFieldA, 0) + Nz(Me.txtFieldB, 0)
End Sub

--
There's ALWAYS more than one way to skin a cat!

Answers/posts based on Access 2000/2003

Message posted via AccessMonster.com


.Ling

I am following John advise and it sound like if I try to do whated I
started to do,it gets too hairy

 

[Jamo]

--
Center for technica education

Thank you so much for the information. I will delete that field out of
the table and create a report to do the total calculation, however for my own
curosity can that be done what I was trying to do in a form? I will follow
you advice and proceed from here

Well, you can't do calculations in tables - but you have at least three other
choices!

You can do a calculation in a Query by just typing the calculation expression
in a vacant Field cell:

Total: [FieldA] + [FieldB]

Or you can display a calculation on a Form by putting an expression in the
control source property of a form Textbox:

= [FieldA] + [FieldB]

The same technique works on a Report as well.

If you want to sum the value of a field across multiple records, you can also
do it three (or more) different ways: with a Totals Query; or in the Footer of
a Form or Report:

= Sum([FieldA])

So you're not losing much by being unable to do the calculation in a table.

SideNote: Access 2010 has <sigh> calculated fields in tables. In reality
they're a hidden query, and in fact this can be a useful technique, but you do
need to understand the underlying logic.

Thank you so much,but I think I will follow your suggestion and either
do it in a query or a report.