Can you create a global field that can be for all tables in a database, or do you have to access it from one table to another via the relationship? For example on many of my screens it will say the year 2009. I set a global field in tableA with the year. I want my layouts from tableB to also say 2009. Can I create this global field just once? Do I have to access the year through a relationship from table to table? Hope I'm making some kind of sense. Thanks.

Mike

Global fields are accessible even from unrelated tables.

Can you create a global field that can be for all tables in a database, or do you have to access it from one table to another via the relationship?

As long as the tables are inside one file, could the global be seen from all tables, but calc's derived from these globals will only render if they are in the same table. I would hessitate to use globals, since you might cure a flaw in your relational structure with it?

--sd

I set aside at least one table just for global fields.

Can you explain that some more. I'm not sure I fully understand the problems with global fields. Are you saying I should make a regular field in each file with the same exact data in each record? I think I recall that when I put my files on FM server, the globals never stayed with the new values. If there is so much trouble with globals, what's the best way? Didn't understand the sepoarate table idea, because, aren't they still global fields? I must be missing something.

If there is so much trouble with globals, what's the best way?

What's the best way to do what? If all you want is the current year showing on every layout, you could simply type // on the layout and format it to display only the year.

I don't think there's any "trouble with globals" - as long as you understand what they do and use them appropriately.

I think you're replying to Soren. Try to reply to the post itself, it saves some confusion.

Sorry. I was replying to both. I'm not sure how you use one table for global fields. Aren't they still global fields?

Mike

If global fields are for general use between tables, how do you decide which table to put them in?

It's often one of those 6 of one, half dozen of the other decisions. DJ is suggesting a table for globals. These would be globals that are:

1. NOT used for relationships needing the global to be in another table (kind of obvious, but important).

2. Usually globals called by various other tables.

One advantage I've found with a Globals table, other than reducing clutter in the data tables, is that if you are developing offline mostly, then putting the file up on the server, it is important to clear globals which appear on layouts. This is easiest done with a Shutdown script. Having these globals in one table makes it easier.