Calculated fields - Storing them or not, forcing them to calculate

  • Follow


Is it possible and/or desirable to have calculated fields recalculate
when they are viewed and not when their dependent fields change?  Is it
possible and/or desirable to not store calculated fields?

If so, how?

I've only used calculated fields that are stored with a record and
are only recalculated if the fields it is dependent on change.  While
this works, it has drawbacks.

Storing the result eats memory.
A new calculated field in existing records won't calculate until
something changes.
Batch updates to a Filmmaker server are slowed when recalculation takes
place as it is updated.

I've been reading old (2001) posts that seem to indicate that storage
can be turned off
"Do Not Store Calculation Resulkts - Calculate Only
when Needed" Tim Booth in "concantenation works how?" I found it
searching Google groups with "calculated field storage".

This seems to be a FM6 thing since I can't find it in 7.  Is global
storage what I want here?

Thanks much in advance,

Russ

0
Reply kosherpiggy (7) 12/20/2005 8:23:22 AM

Out of old habits, I tend to include a "Calculate" button on my layouts 
that executes script to do the calculations, rather than using 
(automatic) Calculate fields. One reason is to retain historical records 
when the factors in the calculation change (eg a change to tax rates).

My ancient Open Access 4 database (circa 1988!) had "virtual fields" in 
its reports that did not take up storage space in the database but could 
be used for complex temporary calculations, including summary data. Your 
FM6 discovery seems to be similar.

So... I cannot help you but am interested in a solution.

Michael Paine



kosherpiggy@hotmail.com wrote:
> Is it possible and/or desirable to have calculated fields recalculate
> when they are viewed and not when their dependent fields change?  Is it
> possible and/or desirable to not store calculated fields?
> 
> If so, how?
> 
> I've only used calculated fields that are stored with a record and
> are only recalculated if the fields it is dependent on change.  While
> this works, it has drawbacks.
> 
> Storing the result eats memory.
> A new calculated field in existing records won't calculate until
> something changes.
> Batch updates to a Filmmaker server are slowed when recalculation takes
> place as it is updated.
> 
> I've been reading old (2001) posts that seem to indicate that storage
> can be turned off
> "Do Not Store Calculation Resulkts - Calculate Only
> when Needed" Tim Booth in "concantenation works how?" I found it
> searching Google groups with "calculated field storage".
> 
> This seems to be a FM6 thing since I can't find it in 7.  Is global
> storage what I want here?
> 
> Thanks much in advance,
> 
> Russ
> 
0
Reply Michael 12/20/2005 9:55:00 AM


Turning calculation on or off is in the same place in 7 as it is in 6:

With the field's Specify Calculation dialog open, click the "Storage
Options" button near the bottom right of the pane.

You'll find the "Do not store calcualtion results" option there.

Matt


kosherpiggy@hotmail.com wrote:

> Is it possible and/or desirable to have calculated fields recalculate
> when they are viewed and not when their dependent fields change?  Is
> it possible and/or desirable to not store calculated fields?
> 
> If so, how?
> 
> I've only used calculated fields that are stored with a record and
> are only recalculated if the fields it is dependent on change.  While
> this works, it has drawbacks.
> 
> Storing the result eats memory.
> A new calculated field in existing records won't calculate until
> something changes.
> Batch updates to a Filmmaker server are slowed when recalculation
> takes place as it is updated.
> 
> I've been reading old (2001) posts that seem to indicate that storage
> can be turned off
> "Do Not Store Calculation Resulkts - Calculate Only
> when Needed" Tim Booth in "concantenation works how?" I found it
> searching Google groups with "calculated field storage".
> 
> This seems to be a FM6 thing since I can't find it in 7.  Is global
> storage what I want here?
> 
> Thanks much in advance,
> 
> Russ



-- 

0
Reply Matt 12/20/2005 10:32:04 AM

Apparently, I don't know where it is in either then.  Let me give you
a little more info and maybe you can tell me where I'm going wrong:

I'm using winXP .
I have FM 5 7 and 8 available to me.

I create the field in define database.
I click "Options".
In the Auto-Enter tab, I click "Calculated value".
This gets me into "Specify Calculation" which you mentioned in your
post.
However, the only things in the bottom right corner are "OK" and
"Cancel" buttons
On the bottom left there is a "Do not evaluate if all referenced
fields are empty" but that is not it.

I have also tried looking under the storage tab that is back on the
"Options for field" dialog.  All I find there is global storage,
repeating and indexing.

I suspect I've ended up in the wrong place some how.  Is there some
Mac vs. PC confusion going on here? 

Thanks for the help,

Russ

0
Reply kosherpiggy 12/20/2005 6:56:24 PM

You're not working with a calculation field then.  You're working with
a field that has an auto-enters a calculation.  You can change that
value via data entry.

Try selecting Calculation as the Type of field instead of Text, Number,
etc.

G

kosherpiggy@hotmail.com wrote:
> Apparently, I don't know where it is in either then.  Let me give you
> a little more info and maybe you can tell me where I'm going wrong:
>
> I'm using winXP .
> I have FM 5 7 and 8 available to me.
>
> I create the field in define database.
> I click "Options".
> In the Auto-Enter tab, I click "Calculated value".
> This gets me into "Specify Calculation" which you mentioned in your
> post.
> However, the only things in the bottom right corner are "OK" and
> "Cancel" buttons
> On the bottom left there is a "Do not evaluate if all referenced
> fields are empty" but that is not it.
>
> I have also tried looking under the storage tab that is back on the
> "Options for field" dialog.  All I find there is global storage,
> repeating and indexing.
>
> I suspect I've ended up in the wrong place some how.  Is there some
> Mac vs. PC confusion going on here?
> 
> Thanks for the help,
> 
> Russ

0
Reply Grip 12/20/2005 7:38:01 PM

Perfect!  Thank you very much.  I just had the two concepts confused
with each other.

If you don't mind, I have a follow up question. Can you tell me when
each should be used?  A stored calculated field seems to be much like a
field that auto enters a calculation.

Is the difference when they are calculated?

I'd like to know what the best practices are with these things.

Thanks much,

Russ

0
Reply kosherpiggy 12/20/2005 8:23:07 PM

kosherpiggy@hotmail.com wrote:

> Perfect!  Thank you very much.  I just had the two concepts confused
> with each other.
> 
> If you don't mind, I have a follow up question. Can you tell me when
> each should be used?  A stored calculated field seems to be much like
> a field that auto enters a calculation.
> 
> Is the difference when they are calculated?
> 
> I'd like to know what the best practices are with these things.
> 
> Thanks much,
> 
> Russ

A calculation field can continuously re-calculate its value according
to  changes to the fields in the calculation.

Auto-Entering a calculation happens in what is otherwise a "standard"
field. Once the value is in, it's in. No changes unless you script
something to change it.

Matt
0
Reply Matt 12/20/2005 10:00:05 PM

I belive Matt is correct if Do not replace existing value for field is
left checked.  I think I failed to be specific enough with my question
though.

Lets say I do the following:
create a text field named Auto that auto-enters FirstName & " " &
LastName.
  Uncheck "Do not replace existing value for field (if any)

create a calculated field named Calc that calculates FirstName & " " &
LastName.
  In storage options I leave "Do not store results" unchecked.
  Calculation result is "Text"

What, if anything, is now different about these two fields? Auto and
Calc seem to do the same thing with these settings.

If Auto replaces everytime and Calc stores the only thing I can think
is left to make them different is when they calculate.  When displayed
or when dependent fields change (FirstName and LastName).

The only other difference I can see is if you make it one way you get
different options then if you make it the other way.

Or am I just confused again?

Thank much to all of you who have responded,

Russ


Matt Wills wrote:
> kosherpiggy@hotmail.com wrote:
>
> > Perfect!  Thank you very much.  I just had the two concepts confused
> > with each other.
> >
> > If you don't mind, I have a follow up question. Can you tell me when
> > each should be used?  A stored calculated field seems to be much like
> > a field that auto enters a calculation.
> >
> > Is the difference when they are calculated?
> >
> > I'd like to know what the best practices are with these things.
> >
> > Thanks much,
> >
> > Russ
>
> A calculation field can continuously re-calculate its value according
> to  changes to the fields in the calculation.
>
> Auto-Entering a calculation happens in what is otherwise a "standard"
> field. Once the value is in, it's in. No changes unless you script
> something to change it.
> 
> Matt

0
Reply kosherpiggy 12/20/2005 11:15:13 PM

A calculation field can't have anything entered into it.  It is always
the result of the calculation.

The auto-entered field can hold whatever its field type allows.

For instance:
FirstName and LastName are text fields

calcFullName is a calculation field of =FirstName & " "&LastName
FullNameLookup is a text with with an Auto-Enter calc of FirstName & "
" & LastName.

For a record you enter:  FirstName: Madonna   LastName: Ciccone

both FullName fields will first contain Madonna Ciccone, but then you
can change FullNameLookup to Madonna and as long as you don't touch
FirstName or LastName your fields will read
calcFullName: Madonna Ciccone
FullNameLookup: Madonna
You can't change a calc field directly via data entry.

I don't know how speed, etc. is affected by either field type, but
certain limitations occur to the Auto-enter calc when you're dealing
with related tables.  I generally use calc fields unless I have a good
reason.

G

0
Reply Grip 12/21/2005 12:58:37 AM

Another advantage to using calc fields is that you can make them
unstored.
For things like "Get ( RecordNumber )" you must have the field unstored
to evaluate properly.  Unstored fields don't require any space in the
database which means you can create and delete records without any
slowdowns.
You can not have a unstored calc as the match field in a relationship.

0
Reply FP 12/21/2005 3:42:03 AM

Just wanted to say thanks for all the help.  I learned a lot from you
guys.

Russ

0
Reply kosherpiggy 12/21/2005 6:20:26 PM

10 Replies
248 Views

(page loaded in 0.154 seconds)

Similiar Articles:













7/23/2012 9:25:06 PM


Reply: