Setting a field value for all records from a global sort of value

[bac mac]

What is the recommended method for someone to set a sort of global type of variable so that it will be the value for a field in all of the records and only need to be changed very occasionally (two or three times a year)?

I'd like to have a separate table that just contains one record and one field, e.g., current term like "2011-2012". Then I'd like a calculation in another table for the Current Term field in that table to be the value of the current term from the one record table. I can't reference that field in a calculation because the tables are nor related. There must be a much better way to solve this. The reason I don't automatically calculate this from the current date is that one may need to look at the relationships in the context of previous or future terms.

This is for Filemaker Pro 11 Server so I've had to avoid global storage.

Thanks,

Bruce

[bcooney]

Hi Bruce,

One recommended approach is to indeed have a one record table (often called PREFS). In an script that runs on file open (See File Options), you set the values from Prefs to corresponding global fields or $$vars. Once the value is in the global, it can be referenced from any calc without a relationship to the PREFS table.

I don't understand your concern that this is for FMSv11 and why you avoided global storage. Perhaps you can expand on that and I can help clarify your understanding of globals and FMS. Remember, FMS also runs any Open Script and so would be able to reference a global value. However, each client gets their own "copy" of the global in their session.

hth,

Barbara

[bac mac]

Barbara- I'll try the Prefs table. I already have an Open Script and I can add some settings to the top of it.

With respect to the globals- Relationships were ceasing to function with the database being handled by Filemaker Server although they worked fine when I then copied the database and tested it with just with Filemaker Pro 11. Some of the relationships on the server were then repaired by getting rid of global storage for a couple of variables involved in the relationships. I searched around and I thought I saw something about the server handling global storage differently than stand alone Filemaker. I'm not sure why the server handled things differently.

-Bruce

[bcooney]

I usually have an Update Globals script which goes to a Prefs-based layout and sets the corresponding global fields. The global fields can also be in the Prefs table.

I call the Update Globals script from my OPEN script. Remember to confirm that you are in the correct context when you update your global fields.

When you host a file, the global field values default to the last value that they contained when the file was single user. I don't count on that, but always explicitly set global field values. Perhaps this explains why your relationship (which presumably had a global field on the left-hand side) was not functioning as expected? Also remember, each client has their own global field values for their session.

[bruceR]

Another issue with server and globals: global fields set by a server-side scheduled script retain those values for all users who connect after the server script has run.

[bcooney]

Yes, Bruce, that is true. However, since each client runs my set globals script on open, the fact that a server scheduled script has changed the default global values isn't something that would affect my solution. Or, am I missing something subtle?

[bac mac]

What was mysterious to me was the fact that the global field that was a problem with the relationship looked fine in a layout displaying that field but eventually developed relationship problems likely due, as you suggest, playing with that fields value differently while the database was single user vs. reinstalled in FMS. But the field always looked OK.

1. How do I "confirm that you are in the correct context when you update your global fields"? I'm not sure what is meant by context.

2. So I can use global storage for a field in a relationship as long as I assign that field during an open script and it should work if I:

a. set the current term in the Prefs table, not globally stored

b. during the open script assign that value from the Prefs table current term field to a term field in an unrelated table and have that term field stored globally.

Correct?

[bruceR]

No, Barbara, you've got it. If an opener script sets globals; you're covered. I just wanted to make sure this detail wasn't omitted.

[bcooney]

@BruceR - good to know, thanks.

@bac mac-

1. You must understand context. Context, simply put, is where you are on the relationship graph. Since a layout is based on a table occurrence, then going to a layout places you on that TO. So, if you want to use Set Field to populate a global field from a Pref value, you need to be on a layout based on the PREF table. (You can set global fields from any context). Many novice users have problems with Set Field simply because they are grabbing values "out of context."

2. a. Yes

b. Yes (I usually name my pref fields like this so that they group together when listed alphabetically:

term (text or number field)

term_g (storage set to global).

Oh, and don't forget to set global storage. Common mistake is to name a field with a "g" and not set the storage. We've all done it.

[bac mac]

Thanks all! I now have an understanding of context in Filemaker. I appreciate all the tips, Bruce