One of the things that bothers me about FileMaker is the lack of global variables. I know that a Variables plugin is available and would welcome any comments on it. In the meantime, however, I'm trying to figure out how to share information between files without having to resort to all sorts of copy-and-paste maneuvers.

One of the ideas I had was to create a single record file called Variables that contains a number of global fields. This file would also contain a variable match field that would be used to relate it to all the other files in the solution. Let's say that the match key is the letter "X". Each of the database files would contain a variable match field as well. Whenever a new record is created, this file would automatically contain an "X" as well, thus relating every record in every file back to the variables file.

The way I see it, this would allow for easy passing of data without lots of copying and pasting (a personal pet peeve of mine). Plus one could use the "Set Field" script step on layouts that don't contain the data one needs to copy, thus eliminating the need for freezing the window, switching to a different layout, etc. when copying information.

Is a master variables file a good idea? What would be the reason(s) to not implement such a solution?

Thanks very much for your advice!

-Rob

A variation of this idea has been discussed on and off here before. There are times in a networked environment when you want to have a value that is common to every record in a file. A global field in a networked solution isn't global to more than one client machine and even then is global only for the current session, so a solution is to create a one-record file that contains regular fields (non-globals) and then relate all the files that need these universal values via a constant-to-constant relationship.

This is pretty much what I had in mind. Let's say I have 20 files in my solution. Every record of each file will contain a field called "variable_match" that upon creation will contain an "X". A variables file, with a single record, will also contain a "variable_match" field with an "X". This will allow a constant-to-constant relationship between each file and the variables file. The variables file will also contain a number of global fields to be used throughout the user's session. Since this will be a networked soluion, I want each user's variables to be different, and session-based, hence the use of globals. So far so good, right?

I have thought of a number of potential problems, however. First, I'm going to assume that every file contains at least one record, so that the relationships will work. Will having this "variable_match" field in each file on every record add a lot of overhead? Could the same thing be accomplished by making it a global in each file and having the Startup script automatically insert an "X", thus making the relationship back to the Variables file work for that session? The only other potential problem I can see is needing to access the Variables file when the Fount Count in the current working database is 0. I seriously doubt this will ever happen, but I'm trying to cover all of my bases.

Thanks again for all your help and advice, John. Much appreciated!

-Rob

Rob W. said:

This is pretty much what I had in mind. Let's say I have 20 files in my solution. Every record of each file will contain a field called "variable_match" that upon creation will contain an "X". A variables file, with a single record, will also contain a "variable_match" field with an "X". This will allow a constant-to-constant relationship between each file and the variables file. The variables file will also contain a number of global fields to be used throughout the user's session. Since this will be a networked soluion, I want each user's variables to be different, and session-based, hence the use of globals. So far so good, right?

I have thought of a number of potential problems, however. First, I'm going to assume that every file contains at least one record, so that the relationships will work. Will having this "variable_match" field in each file on every record add a lot of overhead?

Naw...it's just one field we're talking about. I use a calculated number value, cConstant, that is set to equal "1" so that every record I create automatically has this value. Other folks here use a regular number field that auto-enters a "1". Take your pick.

Could the same thing be accomplished by making it a global in each file and having the Startup script automatically insert an "X", thus making the relationship back to the Variables file work for that session? The only other potential problem I can see is needing to access the Variables file when the Fount Count in the current working database is 0. I seriously doubt this will ever happen, but I'm trying to cover all of my bases.

Found counts of zero records do happen, and will mess with things. But at that point, there isn't much your user and do anyway, since there are no records for them to interact with. I generally have a Find All script step after I've informed my user that no records were found.

Thanks again for all your help and advice, John. Much appreciated!

-Rob

Any time.

I use this technique on my projects with very good results.

I define a bunch of global fields in this file which will then be private for each user. I use these to pass data between scripts in different files so I don't have to worry about setting up additional relationships between each pair of files that need to transfer data between them.

I also have regular text and number fields in this file for data that I want to be public to all users on a multi-user solution. These behave as public variables as opposed to the private variables you get when you use global fields.