Dan said:i have a calculated field in my form and its not storing
the data in the table someone told me to create another
field and bind this field to the calculated one does
anyone know how to do this?
-----Original Message-----
Dan,
This is a common misunderstanding about Access forms, raising two points.
Firstly, since most forms are used to display and enter information into
fields in a table, it's easy to think of *fields*, which exist in a table,
and *controls*, which exist on forms (and reports) as the same thing. They
aren't.
Form controls--textboxes, combo boxes, list boxes, checkboxes, option
groups--needn't be bound to a field. If they are, the control's Control
Source property is the name of the field in the table, and data entered into
the control is automatically stored in that field. If you have set the
Control Source property to a calculation, however, such as
=[Qty]*[ListPrice], then the result of this calculation is displayed in the
control, but, necessarily, it cannot be simultaneously bound to a field. To
do so will require VBA code.
Secondly, it is *almost* never desirable to store the result of calculation
in the underlying table. This value is a "snapshot" based on the current
values of all the fields (and unbound controls if applicable) used in the
calculation. If those values were changed outside the context of your form,
the calculation would not occur, and the stored value would then be
incorrect. Moreover, it is slower to read the stored calculated value from
disk than to recalculate it on the fly whenever you need it--for display in a
form, printing it in a report, displaying it in a query, etc.
The exception to this guideline is time-based information- -when one of the
fields involved in the calculation will eventually change, e.g., pricing.
Even in that case, my preference, and, I think, that of most developers,
would be to store a snapshot of the current list price in the table, and
*still* calculate on the fly, rather than store the calculation itself.
There are, no doubt, cases where storing the calculation makes sense,
however, and yours may be one of them. If it is, add a control to your form
bound to the field in which you'd like to store the calculation, and set its
Visible and Enabled properties to No. Then add the following code to the
AfterUpdate event procedure for each control involved in the calculation, so
that if any of them changes, the calculation will be stored.
Me!YourInvisibleControlName = Me!YourCalculatedControlName
HTH
Sprinks
.Dan said:i have a calculated field in my form and its not storing
the data in the table someone told me to create another
field and bind this field to the calculated one does
anyone know how to do this?
Dan said:i went to the form and up top in the field list i drug
down the same field into the form (i assume this made it
bound) i then changed the visible property to no and put
in Me!text56 = Me!estimated recovery but it doesnt work
what am i doing wrong?-----Original Message-----
Dan,
This is a common misunderstanding about Access forms, raising two points.
Firstly, since most forms are used to display and enter information into
fields in a table, it's easy to think of *fields*, which exist in a table,
and *controls*, which exist on forms (and reports) as the same thing. They
aren't.
Form controls--textboxes, combo boxes, list boxes, checkboxes, option
groups--needn't be bound to a field. If they are, the control's Control
Source property is the name of the field in the table, and data entered into
the control is automatically stored in that field. If you have set the
Control Source property to a calculation, however, such as
=[Qty]*[ListPrice], then the result of this calculation is displayed in the
control, but, necessarily, it cannot be simultaneously bound to a field. To
do so will require VBA code.
Secondly, it is *almost* never desirable to store the result of calculation
in the underlying table. This value is a "snapshot" based on the current
values of all the fields (and unbound controls if applicable) used in the
calculation. If those values were changed outside the context of your form,
the calculation would not occur, and the stored value would then be
incorrect. Moreover, it is slower to read the stored calculated value from
disk than to recalculate it on the fly whenever you need it--for display in a
form, printing it in a report, displaying it in a query, etc.
The exception to this guideline is time-based information- -when one of the
fields involved in the calculation will eventually change, e.g., pricing.
Even in that case, my preference, and, I think, that of most developers,
would be to store a snapshot of the current list price in the table, and
*still* calculate on the fly, rather than store the calculation itself.
There are, no doubt, cases where storing the calculation makes sense,
however, and yours may be one of them. If it is, add a control to your form
bound to the field in which you'd like to store the calculation, and set its
Visible and Enabled properties to No. Then add the following code to the
AfterUpdate event procedure for each control involved in the calculation, so
that if any of them changes, the calculation will be stored.
Me!YourInvisibleControlName = Me!YourCalculatedControlName
HTH
Sprinks
.Dan said:i have a calculated field in my form and its not storing
the data in the table someone told me to create another
field and bind this field to the calculated one does
anyone know how to do this?