recalculate button

[zab]

Hi everyone

Can someone help me with this.

If number field A = "5"

field B is an auto-enter-calculation containing : field A * 5

so my result in field B is 25 and it can't change.

Let's say, later, I made a mistake and want field A to = "6" now my field B won't recalculate because it's an auto-enter calculation (And I need it to stay that way).

Is there a way to create a button (or something) that would trigger a recalculation of field B when I need it?

In one table I Have a dozen number fields like Field A and another dozen number fields with auto-enter calculation like field B. So at the push of a button I'd like them all to recalculate.

thank you

[LaRetta]

Hmmmm, I think the new Recover feature to only reindex all fields might work but I cannot test it right now. Back up first. Otherwise, all you need is to force FM to focus on each record which can be accomplished a few different ways:

1) Go into field definitions and set the field to indexed calculation, exit field definition then go back in and change it back to auto-enter (replace). But you must do this with each field independently.

2) Set any field (which exists in the calculation) to itself. So, using Replace Field Contents (by calculation) when your have selected field B would just contain the field name again, ie, calc dialog = FieldB. Again, this is field-by-field basis unless these fields use a common field amongst them.

Reindexing multiple fields (particularly when there is an index issue) has always been a problem; the new Recover methods (only reindex) might be your salvation here, as well as for others elsewhere.

But I have three more points:

• Unless a User is able to override the calculation and need to be able to change the data in FieldB, you should use calculation and not auto-enter.
• "In one table I Have a dozen number fields like Field A and another dozen number fields with auto-enter calculation like field B" sends shivers through me. I suggest that they probably would work better as related table - not always but usually.
• It sounds like you are hard-coding a value within a calculation (the 5 you want to change to a 6), such as if rates change. And you might consider keeping these values in another table instead so, if you change it in one location in Preferences, it will change automatically through ALL your calculations.

We cannot advise in more depth without more information but the three points I mention are important enough to explore further, if you wish. :wink2:

Edited March 19, 2009 by Guest
Changed to list format

[zab]

This part of the database is used to estimated the time of production and some variables will be adjusted overtime.

That's why I need an auto-enter calculation because I don't want all the records to be updated when we'll change the variables. And no one can modify the field B.

But while entering the data, the user can make mistakes or the project can have slight modifications over time. So if field A need to be modified I want Field B to recalculate. That's why I was thinking of a button. To tell the user if you change anything just push the recalculate button. But most of the time once field A is completed the process will stop there.

About the new recover, if you mean in FM 10, I can only use 9 with our actual windows XP computer and server.. even if I have fm 10 on my mac.. talk about a pain. But it look a bit too agressive I don't think that is what I need.

"2) "In one table I Have a dozen number fields like Field A and another dozen number fields with auto-enter calculation like field B" sends shivers through me."

Lol, ok let me think about it." It seems like the easiest way to put everything related to a project in the same place. But I split it in two layouts.

An example so you can understand this part of the project:

table 1

ProjetcID = number

starting_date= date

wall_linear_feet = number

wall_type = value list (osb, codebord, sheating)

wall_isolation - value list (yes, no)

wall_linear_feet_shapes = number

and more...

estimation_wall_cutting = wall_linear_feet * table2::wall_cutting

estimation_wall_assembly = Case ( wall_type = "Sheating" ; wall_linear_feet * table2::wall_assembly sheating;

wall_type = "OSB" ; wall_linear_feet * table2::wall_assembly_osb;

and so on...

;"" )

estimation_wall_isolation = If ( wall_isolation = "yes" ; wall_linear_feet * table2::wall_isolaton ; "" )

and more...

table 2 (variables in fields and not in $$variable or code because I need the user to update those values at will)

wall_cutting = 2.5 (minutes per linear feet)

wall_assembly sheating = 12

wall_assembly_osb = 15

wall_isolaton = 15

and more...

And I created all kinds of reports....

So you see if we need to add an extra 50 linear feet to a project, the estimation field won't update. But I can't make it a calculation because in a few months, after evaluating the stat we'll get from those records, we may decide that cutting the piece for the wall really take 2 minutes. But I don't want the previous pr0jects records to recalculate.

So do you stil think it's better to seperate the first part of the table 1 and put the estimation auto-calculation in another table?

Thanks

Isabelle

[comment]

Hi Isabelle,

I am afraid this is but a replay of your previous thread:

http://fmforums.com/forum/showtopic.php?tid/201407/

You wouldn't have this problem if you looked up the estimated times into local fields, instead of using the Case() calculations.

[Fitch]

So is it a calculated field or a number field with an auto-enter calculation? If the latter, it seems to me you just uncheck the "do not replace" option and you're done.

[comment]

But then you have no control over the recalculation process. True, it won't recalculate if you only change the related value. But if you modify a local quantity field, it will always recalculate using the CURRENT related value - whether that's what you want or not. With a lookup, as long as you don't relookup the related values, it will keep using the historical ones.