dbTalk Databases Forums  

Calculations vs Fields defined as calculations

comp.databases.filemaker comp.databases.filemaker


Discuss Calculations vs Fields defined as calculations in the comp.databases.filemaker forum.



Reply
 
Thread Tools Display Modes
  #1  
Old   
Buckbuck
 
Posts: n/a

Default Calculations vs Fields defined as calculations - 07-27-2010 , 01:26 PM






FM8.5

I have a series of Net results based on calculations. I want the
results to recalculate when the variables change. At the moment this
does not happen - my fields are numbers with calculation results.
Should they be fields defined as calculations instead. Before I go and
change everything perhaps someone can give me some insight.

Thanks
Matthew

Reply With Quote
  #2  
Old   
David Stone
 
Posts: n/a

Default Re: Calculations vs Fields defined as calculations - 07-27-2010 , 02:33 PM






In article
<a221bb0d-8c60-4025-89f6-2b89293eb95f (AT) z30g2000prg (DOT) googlegroups.com>,
Buckbuck <buck.matthew74 (AT) yahoo (DOT) com> wrote:

Quote:
FM8.5

I have a series of Net results based on calculations. I want the
results to recalculate when the variables change. At the moment this
does not happen - my fields are numbers with calculation results.
Should they be fields defined as calculations instead. Before I go and
change everything perhaps someone can give me some insight.
I'm not sure what exactly you mean here!

You can:

(a) create a simple number field
(b) create a number field and set an auto-enter calculation
(this may not update if referenced fields subsequently change)
(c) create a calculation that returns a number, and that may or
may not use other existing fields (this will update if
the field contents change)
(d) create a summary field of various kinds

Which is it you have done? Which is it that you want?
Does your calculation simply involve fields within the same record,
or do you need a calculation across different records?

A bit more information and clarity would be helpful...

Reply With Quote
  #3  
Old   
Bill
 
Posts: n/a

Default Re: Calculations vs Fields defined as calculations - 07-27-2010 , 03:13 PM



In article <no.email-576C2E.15331327072010 (AT) news (DOT) eternal-september.org>,
David Stone <no.email (AT) domain (DOT) invalid> wrote:

Quote:
In article
a221bb0d-8c60-4025-89f6-2b89293eb95f...oglegroups.com>,
Buckbuck <buck.matthew74 (AT) yahoo (DOT) com> wrote:

FM8.5

I have a series of Net results based on calculations. I want the
results to recalculate when the variables change. At the moment this
does not happen - my fields are numbers with calculation results.
Should they be fields defined as calculations instead. Before I go and
change everything perhaps someone can give me some insight.

I'm not sure what exactly you mean here!

You can:

(a) create a simple number field
(b) create a number field and set an auto-enter calculation
(this may not update if referenced fields subsequently change)
(c) create a calculation that returns a number, and that may or
may not use other existing fields (this will update if
the field contents change)
(d) create a summary field of various kinds

Which is it you have done? Which is it that you want?
Does your calculation simply involve fields within the same record,
or do you need a calculation across different records?

A bit more information and clarity would be helpful...
Generally, a calculation field will update when any of the argument
values changes. However, to be sure, you may want to set storage option
for the field to Do Not Store, recalculate when needed. If you need to
use the field in a relationship or a value list, then you should not
check that option, so that the field can be indexed.

A number field can be set to display a calculated value. There is an
option that is checked by default, "Do not replace existing value of
field, if any." Depending on whether you want it to update when an
argument changes, you can uncheck this box in the field definition
Options window.

However, a number field set to display a calculated value generally will
not update if the arguments are from a related table.

So:

If you want the field to always update when an argument changes, make it
a calculation field, and for double assurance, if it does not need to be
indexed, set the Option>>Storage to Do not store calculation results

If you want it to store an historical value based on the arguments at
the time the record was created, make it a number field filled by
calculation.

Reply With Quote
Reply




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 On
HTML code is Off



Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.