Re: Calculated Value will not store in Table
From: Albert D. Kallal (PleaseNOOOsPAMMkallal_at_msn.com)
Date: 09/13/04
- Next message: Jamie Richards: "Re: Data Entry Problem - Form/Subforms"
- Previous message: Allen Browne: "Re: Combo Box dilema"
- In reply to: tonyaims: "Re: Calculated Value will not store in Table"
- Next in thread: tonyaims: "Re: Calculated Value will not store in Table"
- Reply: tonyaims: "Re: Calculated Value will not store in Table"
- Messages sorted by: [ date ] [ thread ]
Date: Mon, 13 Sep 2004 08:37:53 -0600
"tonyaims" <anonymous@discussions.microsoft.com> wrote in message
news:0ef201c49969$34c1d2f0$a301280a@phx.gbl...
> Thanks Albert.
Your welcome...and we seem to be making progress!
>
> What does the "Option Explicit" statement say/do?
Great question!. Option Explicit means that ALL variables you use in code
MUST be defined first.
For me as a developer, that option is thus ALWAYS USED. So, it means that
the "compiler"
will go through all your code, and ensure that you did not miss-type
something; For example
strMsg = "hello, how are you today"
msgbox strMgs
If you look close at the above code, all it does would display a message of:
"Hello, how are you today"
The problem is that I have a type-o in the above (on purpose for this
example). Note how I used:
msgbox strMgs
I misspelled strMgs....it should be:
strMsg
If we use option Explicit, then we MUST define all variables we use, and any
un-defined, or misspelled variable will be instantly found for you by he
computer.. Hence, most developers make the Option Explicit feature the
default. You should do this.
Whack ctrl-g to bring up the developer environment. Then go tools->options.
On the "edit" tab, you want to make sure the 2nd option is checked:
Require Variable Declaration
If you check the above, then ms-access will automatically put in the Option
Exploit into any code module. This option "used" to be the default.
Ok...lets get back to our code:
>
> Anyway, after adding it total price is calculated. I have
> had difficulty with discount. If I enter a 10 then the
> discount is not properly calculated(i.e.: it is treated as
> 10 not .10) but if I enter .1 in the form, it is not
> accepted. The .1 is there until I tab to the next control
> and then it becomes 0 so there is no discount applied. So
> I changed the line in MyTotCalc from
My guess is that your discount field is NOT a currently value. If any of
your fields are integer (long), then no decimals are allowed into the field.
This likely is your problem, and means your table defines for these fields
needs to be checked. I would use currency in these cases, or you could
divide the value entered by 100 if you wish (as you did).
>
> curResult=curResult - (curResult*Nz(DiscPercent,0))
>
> to
>
> curResult=curResult - (curResult*Nz(DiscPercent, 0) / 100)
>
> and entered a whole number as the discount instead of a
> decimal number. Now the TotPrice is calculated correctly
> but the discount is still not stored in the table.
You mean field DiscPercent is not being saved..right? You enter the
DiscPercent, and that gets saved. You calculate the TotPrice, and our code
saves that. Is there actually another field involved here? (because if there
is..we need to set it...and I see no code at all here that sets this
field...if in fact there is another field here?).
Hum...again, I would check the table definitions for this field. I would
suggest using currency type field.
Also, if in fact there is another field, then we are learning a good lesson
here:
Don't store calculate values.
In fact, I should actually said that I will NOT show you how to write this
code, but have FORCED you to come up with a expression that CALCULATES the
result each time. The reason why this "calculating" concept is important is:
We NEVER have to worry about the values being wrong...since we don't
save them
Why save values that you can calculate them (this is one the first
lessons in good database design).
It is easy to accident save the wrong values, and in fact, when we
finally do get our code working, then we don't have to go and check EXISTING
DATA!!! Note that as we enter and test our code, the old data, or other data
entered will NOT be fixed when we finally fix our code.
As you can see, it is often somewhat easier to write a small piece of code
as we did, but at the end of the day, we should have tried to come up with a
design that DOES NOT store these values. We don't need to store them,and can
calculate them any time we need. Further, now you have to start going back
into your system to ensure our data is correct, *after* we get our code
working. If we had come up with a solution that just calculates the results,
then when we get the code correct...we are done! (as it is now, you have to
go back and check the data since our code is not 100% correct!).
Anyway, we shall just have to say that the team of developers and system
analysts made a design decision here. We shall assume that we found it
somewhat easier to store these values. However, some members of our design
team did suggest that we don't store the values, and that good time honored
sound advice about not storing calculated values was taken with fair
consideration! ;-)
Good luck!!
-- Albert D. Kallal (Access MVP) Edmonton, Alberta Canada pleaseNOOSpamKallal@msn.com http://www.attcanada.net/~kallal.msn
- Next message: Jamie Richards: "Re: Data Entry Problem - Form/Subforms"
- Previous message: Allen Browne: "Re: Combo Box dilema"
- In reply to: tonyaims: "Re: Calculated Value will not store in Table"
- Next in thread: tonyaims: "Re: Calculated Value will not store in Table"
- Reply: tonyaims: "Re: Calculated Value will not store in Table"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
