You are currently viewing Thinking Globally

Thinking Globally

FileMaker has some neat features that are pretty much unique to the platform. One of these is so-called “global” fields. (Technically, they’re fields set for global storage … but nobody actually says that.) Setting a field for global storage is helpful in a number of ways, so let’s talk about some of what you can do with global fields, and maybe look at a little demo file.

The first thing to understand is what’s meant by “global” storage. When we set a field for global storage, what we mean is the field has the same value across all records in the table. It does not mean that the field has the same value across all users currently in the database, or that it always has the same value regardless of what you do. (Although there is such as thing as a calculation field with global storage, which gets a little weird. We’re not going to talk about those in this post.) This is an important point. Every user can independently set the value stored in a global field, without affecting the value seen by any other user – and, conversely, what you do with your global field is invisible to any other user.

Another feature of global fields is that, unlike other fields in a FileMaker solution, their values are visible – and editable – from anywhere in the solution. You don’t have to be on a particular layout to see or manipulate the values stored in a global field. (So when we say, “Context is king,” globals get a pass.)

That’s actually a pretty cool combination of features. It means global fields allow the developer to have a “holding bin” for information that’s (a) unique to the user, and (b) accessible from anywhere. Sounds like user settings, right? And that’s how global fields have been used for a very long time. But they have other uses as well.

One thing you can do with global fields is to set a relationship to show a filtered result in, for example, a portal, that is particular not to a given record, but to a given user. Say you wanted a sales rep to see only his own contracts in a portal. You could place that user’s ID value in a global field and use it as a relational key down to a related table, showing only those values relevant to that user. Pretty useful.

Another use that global fields have is for on-screen displays. Now, this function has largely been supplanted by new features like Conditional Formatting and merge variables. However, there are some circumstances where you still might want to use a field. For example, it’s hard to store an image in a variable. (Like, well, impossible.) So a global field can be used to store a company logo that shows up on a layout without needing a relationship back to a central storage location, and without having to copy that information back down to your layout (which will increase the size of the file and the bandwidth requirements).

We’ve prepared a little demo file that covers all these capabilities, along with some scripting to make it work for you. It’s in our resources area, and you can also click this link to access it. Enjoy!

And by all means, if we can help you with any of your database needs, please contact us. We’re always ready to help.