bind a field to another one

[Dan]

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?

 

[Rick Brandt]

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?

Why would you want to save a calculation? Put your current expression in a
query based on your table and then just use the query everywhere you are
currently using the table.

 

[Sprinks]

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]

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

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?

.

 

[Bruce]

So you have decided there is a compelling reason to store the calculation
result? OK. Dragging the field from the field list to the form does indeed
bind the control (text box) to the field. The code needs to go into the
after update event of all fields involved in the calculation, so that a
change to any of them updates the hidden (bound) field.
I suggest giving your controls descriptive names. It will help later. Try
a Google search for "Microsoft Access naming convention" or something like
that.

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

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]

i must be doing something wrong with the code i put
Me!Text56 = Me!Estimated Recovery in all the fields that
involve the calculation but its not working i put this
in the fields that calculate exstimated recovery and
nothing and also then added it to the bound field i
created plus the estimated recovery field and it dont
work im not sure what im doing wrong?

-----Original Message-----
So you have decided there is a compelling reason to store the calculation
result? OK. Dragging the field from the field list to the form does indeed
bind the control (text box) to the field. The code needs to go into the
after update event of all fields involved in the calculation, so that a
change to any of them updates the hidden (bound) field.
I suggest giving your controls descriptive names. It will help later. Try
a Google search for "Microsoft Access naming convention" or something like
that.

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



:

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?

.

.