Hey all, I'm reading the White Paper for FMP Novices by David K. (Foundations Database Systems)

And I am learning a LOT.

I am rebuilding our database (currently, it really is a perfect example of "angry fruit salad"!)

I am only permitted to add necessary fields to existing tables, and create a proper interface to the database. (it is a mess like you would not believe!)

I was thinking about user preferences, for relationships and such (my plan is to have a portal with a list of all items, for example, all quotes, listed in a portal on the screen, with a transparent layer on top of each row, to execute a script to pull up the entire quote when selecting it from the list)

I am thinking about storing all temporary data (user settings, relationship keys, current selections, temp variables) as global fields in one table (they will be saved into an array for that user during the shutdown script, and extracted out of the array when the user logs in)

Is it a common thing to do, to have one table of user preferences, with all other tables related to the global variables within that table.

I still am very new to databases and am learning a LOT with filemaker pro, any advice you can offer would be much appreciated.

Thanks!

It is indeed a useful technique to run a script when your solution is launched that loads user/system prefs into global fields. You don't have to relate them to other tables unless you have a reason to do so. Global fields are available to any script, calc, or layout, even if they are unrelated. That's the main reason I use this technique.

Or you can load them into global variables instead. The advantage of global variables is that you don't clutter up your schema with extra fields, and also it makes your scripts a little more readable IMHO.

Global fields OTOH, can drive relationships (e.g. for portals) and can be "seen" from other files, whereas global variables are file-specific.