Paolo Posted April 30, 2003 Share Posted April 30, 2003 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 More sharing options...
danjacoby Posted April 30, 2003 Share Posted April 30, 2003 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? Link to comment Share on other sites More sharing options...
kyle Posted April 30, 2003 Share Posted April 30, 2003 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 Link to comment Share on other sites More sharing options...
Vaughan Posted May 1, 2003 Share Posted May 1, 2003 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 More sharing options...
Paolo Posted May 5, 2003 Author Share Posted May 5, 2003 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 More sharing options...
cjaeger Posted May 5, 2003 Share Posted May 5, 2003 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 More sharing options...
Paolo Posted May 6, 2003 Author Share Posted May 6, 2003 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. Link to comment Share on other sites More sharing options...
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now