I suggest you post questions separately rather than multiple questions on unrelated issues.
Regarding your preference page. Global's are not the same for more than one user. So FM designers like to load a set of variables each time FM starts up then have these values available as needed.
I prefer to have a utility table with an "X" relationship. My utility table only has one record, otherwise it will not be able to find the correct data.
Apologies. I didn't realise I was posting multiple questions. I did two correction to the original text and 'hit' the post button. It must have created multiple questions.
I have set-up Global fields for logos and addresses in the past and inserted these global fileds on various layouts - they load for all users. The users could change the data in the fields, but the fields are not editable.
I like the idea of the utility table and that is what i have used in the past. I was wondering am I taking an efficient approach to setting up the Management team contacts table?
1 of 1 people found this helpful
I think it depends on how you use the file. If it is hosted (it sounds like it is) data changes to global fields, will only affect all users if you unhost the file first.
The other issue with Global's, is lets say someone makes a correction on the address. Well that will only be seen by that user and when they log on next time, their correction will no longer be there, as it will revert to the global that was set when the file wasn't hosted.
If that is the behavior you want, then no problem. If it isn't, then you need another approach.
As I mentioned some people like loading these as variables so they can be used anywhere at any time. For my solution I prefer the utility table with one record. If there an image (logo) used throughout, I like that in a different utility table.
1 of 1 people found this helpful
"I have set-up Global fields for logos and addresses in the past and inserted these global fileds on various layouts - they load for all users. The users could change the data in the fields, but the fields are not editable."
That's a commonly used approach, but what do you do if the value in one of those fields needs to be changed for all users--say the company updates their logo for example?
Even if you log in with full access, any change made to one of those global fields is only temporary and only visible to you--no one else. So when using such a set of globals, also set up your preferences table of non-global fields to store this data and use a start up script to set the values of the globals from these nonglobal fields. You can then make lasting changes by editing the nonglobal fields.
That means you start with that preferences table either with Tom's method using Cartesian joins or when using globals. There are two differences that can make one option better than the other:
Using globals simplifies your relationship graph. In complex solutions, this is not a trivial thing.
But: any updates to preferences do not appear until the next time a user opens the solution when using globals where it is instantaneous when using the Cartesian join option.
That delay probably doesn't matter for something like a company logo that rarely changes, but for other data that needs to be managed on such a global level it might be an important distinction.