Link to home
Start Free TrialLog in
Avatar of tmonteit
tmonteitFlag for Afghanistan

asked on

Using Globals in Filemaker Pro 9

Background:  This question is another iteration of an example that  this group has helped.  The question is as much for my education as it will help me solve a problem.

Situation:  I want to add another table (Activities) that will query based on the same dates as was used in the expense table.   I noticed, however, that my query dates are elements in the expense table.  Rather than build an Activities table and build 4 fields to match the exact same dates as Expenses, why not just make a global table and have both tables (Expenses and Activities) pull thier dates from the global.

When I wrote Java and Python, and used MySQL, it was considered good practice to have a standard configuraiton file or table for lookup values.  It is a bit confusing to me how filemaker handles globals in this situation?

If I do have to build a seperate Activitees table, there doesn't seem to be an easy way to copy/paste the definitions of one table to another.  Part of me wishes I could simply build my table definitions in a SQL file with vim.



Questions:

What is the best (most elegant) way to handle globals that are referenced by multiple tables in Filemaker?

Why does Filemaker allow  you to set globals within a table definition?  It doesn't seem rational based on other best practices.  (perhaps I'm missing something)
EE-question-08-Aug-2010.png
EE-question-1f.fp7
ASKER CERTIFIED SOLUTION
Avatar of Tocacar
Tocacar
Flag of United States of America image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
SOLUTION
Avatar of North2Alaska
North2Alaska
Flag of United States of America image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
There is no problem with global fields in a multi-user environment as they are session specific and only hold data according to the user's session (50 people could be logged in and they would each have their own private values in the global fields without any conflict whatsoever).  Often, the very benefit of global fields is that they hold information specific to the user so that you can develop scripts, etc. which behave differently according to the user's status (one example).

When you are developing the system on your desktop, if you don't empty out the global fields before hosting it on the server, the last values you had in the global fields will remain in the system (until you unhost the file, clear out the values and re-host it).  Of course, this may be exactly what you want, in which case make sure you store global data in the relevant fields before you host the file on the server.  Any information entered into a global field, while the database is hosted by the server, is automatically cleared when the user logs out.

I would not personally store information intended to be 'global' in regular fields in a single record table as ThomDroz suggests as you will not be able to refer to it from unrelated contexts.  His suggestion to store the data in variables, instead of a global table, however, is a good one (just make sure your variable name has a '$$' prefix (instead of the single '$') otherwise it won't be a global variable).

SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
@ThomDroz

I hear what you're saying, but in order to use your standard fields as global information you would need to clutter your relationship graph with unnecessary cross-join relationships between probably multiple occurrences of your single record table and the table occurrences you wanted to access the data from.  This is especially true if you use the anchor-buoy technique in your graph, which generates more table occurrences anyway, but still has the potential to add significant clutter to the more difficult to maintain 'spider web' graph technique.

A more elegant approach to supplying static global values for all users would be to set global fields with the required data before hosting the file, or by setting global fields/ global variables with required data in a login script.  

A downside of using global variables instead of global fields is that their contents can be modified via the Data Viewer which could be a security concern and lead to unexpected behaviours (if any of your users had FMP Advanced).

As I understand it, the intended purpose of global fields is to supply data globally across the entire system - this can either be session/ user specific, or can just be static values the same for all users that are globally available across the entire system (no extra relationships required).

I hope you don't mind the friendly debate on this topic.  :o)

Tocacar
SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
@jvaldes

Can I ask what problems you have had with a central global table?  Also, in what circumstances has data storage become unreliable in your systems?

Global fields are not dependent on context and you can access them from anywhere in the system (no relationships required).  Depending on their purpose, some global fields have to be stored in the table in which they will be used.  Mostly though, the vast majority of purposes do not require this and so it is fine to store them in a central global table for neatness and easy reference.

Global fields cannot be used as the sole match field in a relationship, because they cannot be indexed.

Avatar of tmonteit

ASKER

Very Helpful!