A Microsoft Office (Excel, Word) forum. OfficeFrustration

If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below.

Go Back   Home » OfficeFrustration forum » Microsoft Access » Using Forms
Site Map Home Register Authors List Search Today's Posts Mark Forums Read  

AccessForm RmPrice*Rms = Amount (doesn't calucate in Amt field)



 
 
Thread Tools Display Modes
  #1  
Old May 8th, 2006, 08:57 PM posted to microsoft.public.access.forms
external usenet poster
 
Posts: n/a
Default AccessForm RmPrice*Rms = Amount (doesn't calucate in Amt field)

I'm creating a Form w/ a combo box(RoomPrice) * (Text box) no of Rooms =
(Text box) Amount$$$. It should calculate new Amount on Form and post in
record

=Room1GAmt[Room1]*[Room1Qty] doesn't work expression builder

But =[Room1]*[Room1Qty] will display on form but not post to record

Help me . It needs post in record for future calculations....

Thanks WR
  #2  
Old May 8th, 2006, 11:33 PM posted to microsoft.public.access.forms
external usenet poster
 
Posts: n/a
Default AccessForm RmPrice*Rms = Amount (doesn't calucate in Amt field)

you have the calculation occuring on the form; thus that text box is a
calculated value....and it can't do double duty in being both a form
calculated value and an input to a record on a table....

now the purists in DB theory say one should never record a calculated value
- by the way - afterall you have the price/room and quantiy in the
table.......so that calculated value is always available to you....but hey....

so what you might want to do is really is to do the calculation in the
table; you can put the calculate value in a field of the table....you might
have to add a 'calculate' button that will close your form and reopen it so
the textbox based on that value will then enter....

more than one way to skin this cat....
--
NTC


"76 Group Man" wrote:

I'm creating a Form w/ a combo box(RoomPrice) * (Text box) no of Rooms =
(Text box) Amount$$$. It should calculate new Amount on Form and post in
record

=Room1GAmt[Room1]*[Room1Qty] doesn't work expression builder

But =[Room1]*[Room1Qty] will display on form but not post to record

Help me . It needs post in record for future calculations....

Thanks WR

  #3  
Old July 9th, 2006, 12:16 AM posted to microsoft.public.access.forms
LAMP90
external usenet poster
 
Posts: 7
Default AccessForm RmPrice*Rms = Amount (doesn't calucate in Amt fiel

Further to this discussion, I have the feeling that what this user really
wants to achieve can be best done by doing the computation in a new query
associated to your table, creating a calculating field, and using that result
in your form, instead of doing this calc in the form itself.

This approach has the advantages of:

+ No calculations need to be stored, as "NetworkTrade" rightly points out.
+ You do not have to repeat this calculation all over your project
= very messy if you have to change it later.

You then simply associate your form to the query instead of to the table
itself,
and use their fields as if they were the table fields themselves. Voil'a!
no more calculations in forms or reports!

I even go to the extreme of creating a query for every table, even if I am
not doing anything special with its data. If I ever need a calc, I do it in
the query, and then can pull that as a field wherever needed. My forms and
reports contain almost no calc fields at all.

My belief is that, in general, it is a waste of time to do calculations
anywhere else other than in a query. Your code usually becomes a nightmare
to maintain later on unless all or most calculations are inside queries.

One BIG exception is that if the calculated value should not change no
matter what happens with your program. For instance, you already invoiced a
customer with a calculated amount somewhere. You do NOT want that value to
change afterwards (I would not). The rationale is, if prices change later
on, that total should not change. Of course, there are other considerations
to this situation as well, but will leave those for your homework.

LAMP90

"NetworkTrade" wrote:

you have the calculation occuring on the form; thus that text box is a
calculated value....and it can't do double duty in being both a form
calculated value and an input to a record on a table....

now the purists in DB theory say one should never record a calculated value
- by the way - afterall you have the price/room and quantiy in the
table.......so that calculated value is always available to you....but hey....

so what you might want to do is really is to do the calculation in the
table; you can put the calculate value in a field of the table....you might
have to add a 'calculate' button that will close your form and reopen it so
the textbox based on that value will then enter....

more than one way to skin this cat....
--
NTC


"76 Group Man" wrote:

I'm creating a Form w/ a combo box(RoomPrice) * (Text box) no of Rooms =
(Text box) Amount$$$. It should calculate new Amount on Form and post in
record

=Room1GAmt[Room1]*[Room1Qty] doesn't work expression builder

But =[Room1]*[Room1Qty] will display on form but not post to record

Help me . It needs post in record for future calculations....

Thanks WR

 




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is Off
HTML code is Off
Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
Form, Subform, Tab key 2nd_Stage_User Using Forms 17 August 25th, 2006 12:30 AM
Control breaks in access report? [email protected] Setting Up & Running Reports 1 September 29th, 2005 05:06 PM
Follow up Question – Convert one field into three fields Doug General Discussion 2 April 9th, 2005 10:21 PM
Design help, please SillySally Using Forms 27 March 6th, 2005 04:11 AM
Supress blank lines in DOCPROPERTY field Mary Formatting Long Documents 10 May 25th, 2004 07:27 PM


All times are GMT +1. The time now is 12:48 AM.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright ©2004-2024 OfficeFrustration.
The comments are property of their posters.