Control Formula displays different result when cursor is on it?

W

WoodyAccess

I have an Orders Subform that is based on a query with all of the information
form the tblOrderDetails and a formula to get the extended price of a product.

The Extended Price formula is

(tblOrderDetails.UnitPrice)*(Quantity)*(1-[Discount])

This all works fine when I click off of the ExtendedPrice control, but when
I click on it, it displays a number just under the actual quantity (ie click
off the control the number is £285 click in the control and the number is
£284.999999776483).

When I then try to Sum([ExtendedPrice]) the result is then slightly wrong

Why is this????
 
B

Bob Hairgrove

I have an Orders Subform that is based on a query with all of the information
form the tblOrderDetails and a formula to get the extended price of a product.

The Extended Price formula is

(tblOrderDetails.UnitPrice)*(Quantity)*(1-[Discount])

This all works fine when I click off of the ExtendedPrice control, but when
I click on it, it displays a number just under the actual quantity (ie click
off the control the number is £285 click in the control and the numberis
£284.999999776483).

When I then try to Sum([ExtendedPrice]) the result is then slightly wrong

Why is this????

Because you are using a floating-point data type such as Double for
what should be stored as Currency in the table.
 
B

Bob Hairgrove

When I then try to Sum([ExtendedPrice]) the result is then slightly wrong

Why is this????

Because you are using a floating-point data type such as Double for
what should be stored as Currency in the table.

Actually, I replied a little too quickly on this. It is possible that
Access is converting the calculated values to Double type behind your
back, but I doubt it here. It usually happens when dividing a value by
another, but Access should be able to multiply a currency value by an
integer without generating any rounding errors. That is why I am
assuming that you are storing the values as Doubles, which is asking
for trouble when dealing with money (as you have seen). The reason is
that Double stores numbers internally in binary floating-point format;
an innocent-looking number such as 1.1 cannot be stored without a
slight rounding in binary form. Currency values are stored internally
as scaled integers, so there is no trouble with storing such a number
100% accurately. You could also use the Decimal numeric type just as
well; that way you could also use a greater number of decimal places
than the default for Currency which is four.

Instead of using a formula directly in the text box control source as
you have it, I would use a custom formula which does the calculation
and returns the value as Currency; then the sums of [ExtendedPrice]
should be correct. You should probably set the Format property to
display two decimal places as well.
 
W

WoodyAccess

I'm not sure this is the case. All my currency values are stored as currency
in their respective tables and the quantity value was stored as double I have
tried as decimal and the form still contains the same answer. I have tried to
put CCur infront of the formula but that again still dispalys the correct
amount when clicked off but the incorrect amount when clkicked on the control.

I'm not sure whether it would make a difference but I have based the form on
an SQL query and put all the fields in the query and made the extendedprice
an expression? I have also used an afterupdate event in the product combo to
select the currency values of UnitPrice from the tblProducts UnitPrice

I'm not very strong with VBA code yet - where and what code would I use to
do the formula for me?

Thanks for your help so far
 
W

WoodyAccess

Thanks for the advice have put the formula in VBA Code and it looks like this

Private Sub Form_Current()

Dim extprice As String

extprice = CCur(UnitPrice * Quantity * (1 - Discount))
ExtendedPrice = extprice

End Sub

Have had to put the formula in each of the Unit Price, Quantity and Discount
after update events to make sure that the formula is followed after every
input (is there a shorter way of doing this?)
 
B

Bob Hairgrove

Thanks for the advice have put the formula in VBA Code and it looks likethis

Private Sub Form_Current()

Dim extprice As String

extprice = CCur(UnitPrice * Quantity * (1 - Discount))
ExtendedPrice = extprice

End Sub

Have had to put the formula in each of the Unit Price, Quantity and Discount
after update events to make sure that the formula is followed after every
input (is there a shorter way of doing this?)

Actually, I believe it would be best to leave it as an expression in
the ControlSource of ExtendedPrice and to put a "Me.Recalc" command in
the AfterUpdate event procedures for the other controls. The form's
OnCurrent event procedure would only run once for each change of row
in the form's underlying recordset.

As to why Access is displaying the number as a double, you mentioned
in your earlier post that Quantity is stored as a double. Why? This is
probably what is causing Access to silently convert the result to a
double. Why can't Quantity be an integer, for example? Is it possible
to order a fraction of something?
 
W

WoodyAccess

Thanks for your replies.

Have done what you suggested and put a Me.Recalc in controls and made
Controls source for the ExtendedPrice a calculation. Have also set the
Quantity to decimal as quantities are not always integers.

Now though I'm having trouble with my Main form Orders Total control. Its
control is =Sum([ExtendedPrice]) but now the controls source has changed to
an equation it does not calculate. Do i just put =Sum([CCur=.........etc])?

And is there any now for the ExtendedPrice that is calculated to be sent
automatically to the OrderDetails (subform) table?
 
B

Bob Hairgrove

Thanks for your replies.

Have done what you suggested and put a Me.Recalc in controls and made
Controls source for the ExtendedPrice a calculation. Have also set the
Quantity to decimal as quantities are not always integers.

Now though I'm having trouble with my Main form Orders Total control. Its
control is =Sum([ExtendedPrice]) but now the controls source has changed to
an equation it does not calculate. Do i just put =Sum([CCur=.........etc])?

It sounds like you are having issues which are more related to the
syntax of referring to subform controls from the main form. The main
thing which you need to do is to rename your controls to something
DIFFERENT than the fields of the underlying recordset in order to keep
from pulling out your hair over issues such as these <g> (... as early
as Access 2, which had serious bugs in this respect, I started doing
this to keep my sanity).

For example, let's assume you have a subform called "MySubForm" and a
main form called "MyMainForm" (not very original, but good enough for
now). When you add the subform to the main form, e.g. by dragging it
from the database window onto the main form in design view, Access
gives it a name automatically which is the SAME as the name it has in
the database window. After you have added it like this, click on the
subform in design view, display the "Properties" popup window, and
give it some other name such as "sfMySubForm" or maybe
"ctrl_MySubForm". The form OBJECT in the database window should retain
the same name it had before, but now you have a distinct name for the
form control on the main form which CONTAINS that form as a subform.

The same logic applies to all the fields in the underlying recordset
of the subform, and for all of the records of the underlying recordset
of the main form.

So if you have a calculated expression called "ExtendedPrice" in the
query for the subform's record source, name the control on the subform
"txtExtendedPrice" (for example) which has "ExtendedPrice" as its
control source.

In your main form, let's say you have a control which should display
the total for that calculated value over all the records displayed in
the subform for the current record of the main form. The control
source for that control (regardless of how you name THAT control; you
seem to have [Orders Total], which is just fine) would be:

=Sum([ctrl_MySubForm]![Form]![txtExtendedPrice])

Note how you have to tack on the "...![Form]!..." bit in between the
two control names.

Hopefully, after you substitute the real names for your subform (and
your renamed subform control on the main form), your problem will be
solved! It might be that you need to put that control in the main
form's footer section, but I'm not real sure about it.

[And if John W. Vinson is lurking here, from whom I learned all of
this in the first place :) -- and if he sees an omission on my part --
John, please feel free to set me straight!]
And is there any now for the ExtendedPrice that is calculated to be sent
automatically to the OrderDetails (subform) table?

Use the BeforeInsert event of your main form (perhaps for the subform)
if you need to store that calculated data. At any rate, you should NOT
store it twice redundantly! If the underlying data for the calculation
doesn't change, you will be better off just displaying the result of
the calculation instead of storing it in the table. If it DOES change
(e.g. discount rates tend to change with time), then you will need to
store the totals as a record of what was actually charged on the bill
(preferably in a different table than the ones used for capturing the
order data.)
 
W

WoodyAccess

You've got me a bit confused now!

Before, the whole form is based on tblOrderDetails. I selected a product
form cboProduct and via AfterUpdate

Me.ctrl_UnitPice = Me.cboProduct.column(2)

automatically filled the ctrl_UnitPrice box (with the relevant price from
the tblProducts). Then all I had to do was input the quantity and the
discount. I had the calculation in the ControlSource of the ExtendedPrice
controlbox and the calculation result was correct.

Now, the formis still basedon tblOrderDetails. I have put the calculation as
an expression (called ExtPrice) in a column of an SQL statement in the Row
Source of my cboProduct. However when I attempt to chage the ControlSource of
the ctrl_ExtPrice to ExtPrice (the name of the expression) the control box
displays #Name?

Should the controlsource be ExtPrice or is there something else I need to
add to make it recogniose that it is an expression from the cboProduct?

How do I get the controlbox in the footer to add up all the calculation
results that appear in ctrl_ExtPrice?
--
Thanks
WoodyAccess


Bob Hairgrove said:
Thanks for your replies.

Have done what you suggested and put a Me.Recalc in controls and made
Controls source for the ExtendedPrice a calculation. Have also set the
Quantity to decimal as quantities are not always integers.

Now though I'm having trouble with my Main form Orders Total control. Its
control is =Sum([ExtendedPrice]) but now the controls source has changed to
an equation it does not calculate. Do i just put =Sum([CCur=.........etc])?

It sounds like you are having issues which are more related to the
syntax of referring to subform controls from the main form. The main
thing which you need to do is to rename your controls to something
DIFFERENT than the fields of the underlying recordset in order to keep
from pulling out your hair over issues such as these <g> (... as early
as Access 2, which had serious bugs in this respect, I started doing
this to keep my sanity).

For example, let's assume you have a subform called "MySubForm" and a
main form called "MyMainForm" (not very original, but good enough for
now). When you add the subform to the main form, e.g. by dragging it
from the database window onto the main form in design view, Access
gives it a name automatically which is the SAME as the name it has in
the database window. After you have added it like this, click on the
subform in design view, display the "Properties" popup window, and
give it some other name such as "sfMySubForm" or maybe
"ctrl_MySubForm". The form OBJECT in the database window should retain
the same name it had before, but now you have a distinct name for the
form control on the main form which CONTAINS that form as a subform.

The same logic applies to all the fields in the underlying recordset
of the subform, and for all of the records of the underlying recordset
of the main form.

So if you have a calculated expression called "ExtendedPrice" in the
query for the subform's record source, name the control on the subform
"txtExtendedPrice" (for example) which has "ExtendedPrice" as its
control source.

In your main form, let's say you have a control which should display
the total for that calculated value over all the records displayed in
the subform for the current record of the main form. The control
source for that control (regardless of how you name THAT control; you
seem to have [Orders Total], which is just fine) would be:

=Sum([ctrl_MySubForm]![Form]![txtExtendedPrice])

Note how you have to tack on the "...![Form]!..." bit in between the
two control names.

Hopefully, after you substitute the real names for your subform (and
your renamed subform control on the main form), your problem will be
solved! It might be that you need to put that control in the main
form's footer section, but I'm not real sure about it.

[And if John W. Vinson is lurking here, from whom I learned all of
this in the first place :) -- and if he sees an omission on my part --
John, please feel free to set me straight!]
And is there any now for the ExtendedPrice that is calculated to be sent
automatically to the OrderDetails (subform) table?

Use the BeforeInsert event of your main form (perhaps for the subform)
if you need to store that calculated data. At any rate, you should NOT
store it twice redundantly! If the underlying data for the calculation
doesn't change, you will be better off just displaying the result of
the calculation instead of storing it in the table. If it DOES change
(e.g. discount rates tend to change with time), then you will need to
store the totals as a record of what was actually charged on the bill
(preferably in a different table than the ones used for capturing the
order data.)
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top