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!

I guess I would ask why I'm using a calc field that refers to a global field, and can I redo the calculation so that it can be indexed.

How does the calc refer to the global, and can it refer to (say) a constant?

hi, paolo ! why don't you go download "Automatically indexing non-indexable fields" pdf articles from cobaltsky's website. it might help you .

http://www.nightwing.com.au/FileMaker

or you can load your file here so that many good people can see your problem and your approach and come up with answer faster.

HTH...

kyle

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.

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.

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 ...

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!!

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.