Jump to content
Claris Engage 2025 - March 25-26 Austin Texas ×

calculation that cannot be stored


Paolo

This topic is 7854 days old. Please don't post here. Open a new topic instead.

Recommended Posts

I'm having troubles with calculation that cannot be stored (expecially those referring global fields) because they cannot be indexed.

If they cannot be indexed they cannot be user in relationships and to populate value lists.

(The specific problem I had is that I was unable to populate a value list - for use in a pop-up menu - with a calculation field referring a global)

Is there a way to work around this?

I created I normal indexed text field and a script that copies the content of the unstored calculation field into the normal field.

The list is populated with the normal field and the script is called just before the value list need to be up to date.

This works but it's very -inelegant-

Any suggestion ?

Thanks!

Link to comment
Share on other sites

If the value in the global field is really a preference of some kind then it can go into a "preferences" file -- a db with just one record. The field can then be used to seed a value list.

Link to comment
Share on other sites

thanks, you helped me making thinks more clear with globals and calculations.

But what about calculations that contain related fields?

Very often I set a calculated field equal to a related field.

I do this to implement "tunneling" between files (accessing the related field of a related field).

But then I lose the ability to index them..

Calculated fields can be substituted with normal fields. Then the calculation is performed via a script called every time the field need to be up to date.

But this tecnique seems very dangeruous to me... for three reasons:

1) The developer may forget to call the script to update the field value.

2) Performance: the script, running over all the records every time, is much slower than the filemaker engine performing the calculation native, on just the records that need to be updated.

3) A record may be looked.

Link to comment
Share on other sites

I do this to implement "tunneling" between files (accessing the related field of a related field).

So why not put it into the first file if it's a 1to1 relation

But this tecnique seems very dangeruous to me... for three reasons:

1) The developer may forget to call the script to update the field value.

2) Performance: the script, running over all the records every time, is much slower than the filemaker engine performing the calculation native, on just the records that need to be updated.

3) A record may be looked.

1) - you are the developer, this would be YOUR fault.

2)- could do a normal field with lookup based on modification date - would only update if record is modified. only problem: lookup is performed AFTER you edited the record. Create your fields in the right order if you have other calcs that rely on this field.

3) -looked(?) locked - lookup would still pull the data ...

Link to comment
Share on other sites

So why not put it into the first file if it's a 1to1 relation

Good question! In fact I have 2 files with a 1-1 relationship.

The files are both a supplier database, linked by the "Supplier_ID".

One file holds main info about suppliers (Main file) and is used in most of my fm solutions. The other one (Aux file) holds a lot of additional information for a small subset of the suppliers stored in the main file. The Aux file is used in only a single solutions.

That's why I splitted the fields in two files.

Do you think this is bad design?

1) - you are the developer, this would be YOUR fault.

Yes!! That's why I worry about this point!! smile.gif

When I develop I try to do things in the present trying to avoid mistakes in the future.

Whenever it's possible I try to follow standard development rules. I try to avoid hacks or workarounds because they are things I'll have to worry about in the future when I'll implement new features or do debugging.

Anyway, thank you for your advices. I'll check out the "lookup" suggestion.

Link to comment
Share on other sites

This topic is 7854 days old. Please don't post here. Open a new topic instead.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.