Global Fields storage gen question

[ljm]

Do people keep a separate table for their global fields or store them in which ever table seems most relevant?

Thanks,

Linda

[John Mark Osborne]

It all depends on your style and how they will be used. Keeping your globals in a separate table can help organize them but sometimes you want them in another table to help drive a relationship. If they are being used in a script, it doesn't usually make a difference where they are being stored.

[Fitch]

A separate table is great now that you can access globals from anywhere with no relationship required. Keeps things manageable. So we use separate tables where possible (e.g. we use one for global graphics) but also as John says, you don't really have a choice when the global is part of a relationship.

[Søren Dyhr]

If I discover myself having sprinkled a solution with globals, am I pretty sure, I got it wrong somewhere along the line in the relational structure!!

--sd

[T-Square]

In my Separation Model application, I have a single globals table in the UI for program logic (which could probably mostly be eliminated in 7/8, but this is a legacy app that had a LOT of globals before), and a separate globals table in the datafile. I use that back end table to store the client's config settings--e.g., the Client Name, Logo, color scheme, preferred formats, registration info, etc. These globals get used on reports and displays.