Summing a bunch of text boxes

[athyeh]

Hello All,

I have developed a form that I have users inputting production numbers.

Txtbox 1
Txtbox 2
Txtbox 3


.
.
.
Txtbox15

As this person inputs into the form, I have a Txtbox TotalProd that I would like to sum up all the numbers that I have entered into each Txtbox1-15

The only way that I can think to do this is to add in an after_update event into each Txtbox1-15 that goes something like:

Private Sub Txtbox1_AfterUpdate 

Me.TotalProd = Txtbox1

End Sub

Private Sub Txtbox2_AfterUpdate

Me.TotalProd = Txtbox1 + Txtbox 2

End Sub

And so on and so forth.. Is there a more efficient way to accomplish my goal?

[amrut]

In the TotalProd textbox, set it's control source to Nz([Txtbox1],0)+Nz[(Txtbox2],0)+ Nz([Txtbox3],0)+.... and so on.

[athyeh]

https://www.accessforums.net/forms/h...ber-33343.html

Thread solved.

[Missinglinq]

That's the way to do it, because despite the logical way of entering this data, i.e. Txtbox1, Txtbox2,
Txtbox3, etc., you really have no idea of what order the user will enter this data! If your Form were based on a Query you could do a Calculated Field, there, but the expression would be the basically same.

Linq ;0)>

[athyeh]

Exactly. I do have a question though, why were you so adamant about the total fields not needing to be recorded? How does it hurt?

[Missinglinq]

1. Re-running the Calculations is almost always going to be faster than retrieving the data.
2. You're wasting space storing easily reproducible data.
3. If one or more components of the Calculation should change, especially thru some action other than thru the original Form, at a date after the original data input, you run the chance that the stored Calculation Value will remain the same, which will then be incorrect.

Linq ;0)>

[athyeh]

1. Re-running the Calculations is almost always going to be faster than retrieving the data.
2. You're wasting space storing easily reproducible data.
3. If one or more components of the Calculation should change, especially thru some action other than thru the original Form, at a date after the original data input, you run the chance that the stored Calculation Value will remain the same, which will then be incorrect.

Linq ;0)>

All excellent points. Thank you.

[Missinglinq]

Just to be clear, like most 'rules' there are exceptions. When dealing with Sales Tax/VAT, which can change, over time, you have the choice of storing the tax rate for each transaction, using the current tax rate, or with storing the calculated 'price + tax'. Every developer has his preference. One way you're storing a calculated value, the other way you're storing redundant data. I had an app where the NextVisitDate was the LastVisitDate + VisitFrequency, where I really had to store the calculated NextVisitDate. But for the vast majority of situations, the rule is still 'do not store calculated values!'

Linq ;0)>