the previous 'versions' all had the temp variables declared within the procedure, thus all were 'initalized' to Zero in/on each individual routine.
To make the earlier routine(s) work, you need to move/place the declarations where they remain in scope throughout the process.
On the other hand, after doing this, you have some un-necessary calculation. Since the declared variables all numeric types, they will be initalized to Zero, so there is little point to the 'Else' part of your routines above, unless someone would be changing the text box contents from the 'If' condition value to zero.
You also do not provide a context for the process. If this is a 'bound' form, the text boxes are initalized from the recordsource bound fields, including the txtTotal (results), only changes to the source text boxes will trigger the before update event. So, if the intent is to generate the value in txtTotal so that it can be 'saved' in the db, it won't happen unless/until some change is made to one of the source terms. That, however, implies that you are saving a calculated value, which is generally not a good thing, and should be discouraged, this -in turn- suggests that the calculation and display of txtTotal should occur in the form current event.
With so many potential issues surrounding this calculation, I think you must be quite new to programming in general and database work in particular. If that is the case, you should get some (serious) help in the concepts behind relational data base operations before proceeding. I don't mean to discourage your efforts, but retrofitting programming is generally exponentially more difficult (and expensive) than propper initial design, thus it may (probably is) cheaper to delay implementation until a propper (correct?) design than to implement a bad design and then 'fix' it with re-design.
MichaelRed
m.red@att.net
Searching for employment in all the wrong places