Think Globally: A Look At Global Fields
by Geoff Mitchell (gsm@geoffmitchell.com)
RATING: Beginner
PLATFORM: Macintosh & Windows
BONUS FILE: REMAIL.FP3
Although they're not unique to any single database application, I consider one of the most versatile and functional features of a well designed database to be the use of Global Fields. They're the greatest thing since, well, FileMaker Pro. I have used them in every database I've designed since I first discovered how much flexibility and power doing so can provide.
Simply stated, a global field is one field, containing a value (be it a number, date, or text string) that is shared throughout every database record. This might initially seem pointless when you view a database as a collection of unique values associated with each record. Let's explore how global fields can open up a whole new dimension to even the most basic development effort.
Do this: Open the REMAIL.FP3 file to follow along
Imagine you're desiging a file that will need to store multiple records. However, there is also a need to manage additional data, identical information for each record, that may need to be revised on demand. Consider the following example: You create a database specifically for sending an email to multiple recipients. Each record is a user's name and email address. But you should only need to enter the email message once. Instead of creating one field for the email body that you must subsequently copy (manually or via scripts) to every record, you can simply create one global field to contain the entire email message. That same message will appear in every database record. If you change it in one record, you change it in every record.
Other potential uses of a global field in this fashion could include designing an address book database that allows the user to enter their own name and address so it will print as the return address in an envelope, or when creating a database that is accessed over the internet you can easily include a 'quote for the day' or 'special of the week' field. In all these cases, a global field provides a solution to share one value through all records while making it easy to change that value as needed. Global fields also take up much less room in a database than a standard field in each record. This makes it an attractive option when you're trying to keep the file sizes small and the access to data as quick as possible.
From my experience, the real beauty of using global fields comes when you start extending your databases to perform steps such as generating emails, customized letters, or even accesing web pages on demand. Using a single global field to manipulate data can provide you with the ability to implement features that will leave your end users scratching their heads and wondering how you managed to incorporate so many useful functions.
I've taken to always having one 'all purpose' global field in my databases by default. I title it •global1 to make it easy to distinguish from standard fields (Windows users may want to use a character other than the bullet, which may be difficult to access unless using the Character Map in the Accessories folder of the Start menu). It's sole purpose is to provide me an easy place to manipulate data on demand. Using that one field I can parse data to update other fields, compose and send emails on demand, open web pages, merge data into text fields, and even control the flows of scripts under special circumstances.
Assume again that you're creating a simple database for generating emails to a list of subscribers. This file contains multiple records, and you need to send one message to all email addresses at once. By using an 'all purpose' global field as a temporary workspace, you can easily do this with one very easy script. You first have the script clear the global field of any existing values (I always assume there's something left over from another script. Of course you could always evaluate the field's contents but that's more script steps and the end result is always the same.. clear it!). Next, build your text string of email addresses, add the necessary text to make it generate the completed email, and use the OpenURL command to do so. (I'm using the OpenURL step in the example below instead of the sendmail step.
I've found that some circumstances are better suited to each, depending on the platform, email client software in use and type of emails being generated. This method works well for brief email bodies and very well when no email body is being created from within FileMaker, but falls short when email bodies might include paragraph breaks or question marks due to limitations of the 'mailto' URL string. In this example, OpenURL enables me to create a simple email message that any platform or email client will recognize).
Go to Record/Request/Page [First]
Set Field ["•Global1" , """"]
Loop
Set Field ["•global1" , "Email Address & "," & •global1"]
Goto next record[exit after last]
End Loop
Set Field ["•global1" , "mailto:" & global1]
OpenURL [No dialog, "•global1"]
That's really all there is to it. This very brief script is an example of how your global field will enable you to manipulate data to suit a very wide variety of needs. Did you notice I was able to refer to the value in the global field while setting it with additional text? I can set the global field to " world" then immediately set it to ["hello" & global1] and the result will be "hello world". You can use this approach for everything from generating completely formatted email messages with merged fields to html documents created on the fly with data from a found set of records. All in one field, with one script.
Happy FileMaking!
Geoff Mitchell has been developing in FileMaker pro for seven years, including a solution still used by Apple Computers, where he is employed fulltime. Check out his website at http://www.geoffmitchell.com.