Using FileMaker Pro

This chapter is from the book

FileMaker 12 In Depth

Learn More Buy

This chapter is from the book

This chapter is from the book 

FileMaker 12 In Depth

Learn More Buy

Working with Fields

If you are used to other productivity applications or have ever filled out a form on the Web, you should find data entry quite familiar in FileMaker Pro. Fields generally look like embossed or bordered areas with labels off to one side or the other, underneath, or above the field. Keep in mind that developers control the look and feel of their systems, so it’s entirely possible that someone could build a database with no labels, fields that are the same color as their background, and white text on a white background. When a field is being actively edited, its border is highlighted (generally darker), and the other fields on a given layout are shown with less prominent highlights, indicating that you’re in the midst of editing a record (see Figure 2.19). Editing fields is as easy as clicking into them, typing some text, and clicking out again. (As with many aspects of FileMaker, these behaviors are customizable in Layout mode.)

Figure 2.19. A downward-pointing arrow might indicate a drop-down field.

NOTE

You never need to save a FileMaker Pro database. As users commit records, those records are automatically stored in the database file. If you want to save a copy of your database or create a duplicate for backup purposes, the Save As option under the File menu will serve.

FileMaker includes spell-checking for text fields, although you can turn it off if you want. When a field is active—when the cursor is in the field itself—FileMaker underlines in red any words it concludes are misspelled. If you right-click (or Control-click on a Mac with a one-button mouse) the word, you can choose from among possible other spellings or save a word to your local dictionary file.

Moving from field to field can be managed on your keyboard if you simply press the Tab key. Some solutions also support the Return and Enter keys. You can, depending on how the developer of a database has set things, tab from button to button or tab panel to tab panel. To execute an action associated with an active button or tab, press the Enter key or spacebar on your keyboard.

• For a discussion of how to control object behavior from a development perspective, see “Working with Fields,” p. 44.

You’ll work with a few different formats of fields in FileMaker Pro:

• Edit box—This allows standard keyboard entry and sometimes includes a vertical scroll bar.
• Drop-down list—When first clicking into a field, you are presented with a list of options from which you can select. Alternatively, you can type directly into the field.
• Pop-up menu—A pop-up menu is similar to a drop-down list, except that a pop-up menu does not allow typing directly into the field.
• Check box set—Check boxes allow multiple values per field.
• Radio button set—These are similar to check boxes, with the difference that they are mutually exclusive. A user can select only one value at a time.
• Pop-up calendar—Some date fields might open to show a calendar that you can page through from month to month. To input a date into your date field, click a specific day.

CAUTION

Shift-clicking allows a user to select multiple values in certain input types, such as pop-up menus and radio buttons. Selecting multiple values in a pop-up menu or in radio button sets is generally a bad idea. You will end up with unpredictable results because you’re making an exception to a formatting choice meant to allow for only one value in a given field.

As the FileMaker Pro interface has evolved, new interface elements have been introduced. Many of the traditional interface elements immediately reveal their functionality: Radio buttons, for example, are instantly recognizable. Some newer features now allow developers to provide hints of functionality that the interface provides. Often this is done by using a light gray for some of the interface elements. Drop-down menus are good examples of this. Even when the drop-down menu is not selected, the small downward-pointing arrow at the right of the field is visible. For the purpose of this book, the arrow is shown darker than it would be in most interfaces; it is usually quite subtle. And do remember that this is the developer’s option: There might be no indication of the field’s capabilities until you click in it and activate the drop-down menu.

A date field can contain a pop-up calendar, as shown in Figure 2.20. As is the case with the drop-down menu shown later in Figure 2.21, the little calendar icon at the right of the date field might be shown in light gray even when the field is not active.

Figure 2.20. Pop-up calendars can ease entry of dates.

Data in Formatted Fields

You might find it helpful to understand how multiple-value data is stored in fields: Remember that check boxes, radio buttons, drop-down lists, and pop-up menus are all nothing more than data-entry assistants. The actual data stored is a collection of values delimited by line returns. This means that you can accomplish the same result, from a data perspective, by simply entering a Return-delimited list of values into your fields. This is an important point for you to remember when performing find requests, which we cover later in this chapter.

• To understand more about how multiple values in a field can lead to relational data structure problems, see Chapter 5, “Relational Database Design.”

Modifying Value Lists

Often, you might need to add new values to a value list—the list that is used to create drop-down lists and pop-up menus, check boxes, and radio button items. Developers have the option of including an Edit option at the bottom of a drop-down list or pop-up menu. Selecting Edit brings up a dialog that you can use to change or add to a list as needed (see Figure 2.21). You can add a separator line to the list by using a single hyphen, as shown in the figure.

Figure 2.21. Editing value lists is a simple way to fine-tune a database to your specific needs without having to dig into programming.

To edit the items in a value list, simply type text into the Edit Value List dialog, followed by a carriage return.

NOTE

Keep in mind that just because you replaced an old menu item with a new category—for example, “autos” became “cars”—doesn’t mean that you changed the actual values stored in your database’s records. Remember that field formatting is nothing more than a data-entry assistant. By changing the assistant menu, you have not changed any data stored in your database.

Using the “Other” Value in Value Lists

Radio button sets and check boxes work a bit differently than drop-down lists and pop-up menus. Developers do not have the choice to add an edit function to these formats; rather, they can include an Other option. This allows users to enter virtually any custom text they want, from a single value to hundreds of lines of text. Regardless of the value, the check box or radio button option visibly displayed is Other; however, the data stored and included in the field’s index includes whatever your other data is. In contrast to adding values to a value list and changing the options available on all records, the Other function simply enables you to enter custom text into a specific record’s field.

As you can guess, developers often disable this feature. Data can get buried behind another entry and can be difficult to account for. Just remember that all you’re doing is using field formatting to help in entering consistent data. These fields are no different from standard fields that accept text data.

TIP

FileMaker Pro is adept at converting data from one type of field to another. If you have a calculation that requires a number, FileMaker Pro happily takes the contents of a text field and converts it to a number. Often this is exactly what you want, although the default conversion of “ten” to a number will not give you the result you might expect.

Despite the built-in conversions, you will get the best performance out of FileMaker Pro if you use the strictest representation of data. If data is a number, use a number field. Dates should be date fields, not free-format text fields.

Field Types

In addition to enabling you to control how data is entered into a field, FileMaker Pro databases use specific field types for different types of information. Field types are independent from the field formatting discussed in the preceding section. For example, it’s entirely possible to format a calculation field as a check box. Calculation fields are different from standard fields; they do not accept data entry and instead present the results of a formula. Although you, as a user, might expect to be able to click on a check box, if you do so, FileMaker Pro prompts you and explains that calculation fields are not modifiable.

It’s incumbent on the developer to sensibly identify, for a given system’s users, which fields expect what sort of data. Often field labels make this clear. For example, you can often expect a Price field to be a number, and an Invoice Date field will no doubt be a date type. You can also use cues (such as the icon for a pop-up calendar) to distinguish fields.

The following list describes the field types available in FileMaker:

• Text—The most common data type, text fields allow a user to enter approximately 2GB of information, including carriage returns. Sorting by a text field is alphabetical.
• Number—Number fields store up to 800 digits, 400 on either side of the decimal, and sort as typical numbers.
• Date—Dates are managed in FileMaker by the Gregorian calendar, 1/1/0001 through 12/31/4000. It’s a good practice, but not required, to use four-digit years when doing data entry. Sorting is by year, month, and day, with the sequence of elements determined by the system settings in effect on your computer at the time the database file was created. This matters only if you commonly deal with date sequences that vary (year/month/day, day/month/year, and so forth). If that is the case, consider using separate fields for month, day, and year to avoid ambiguity.
• Time—Time in FileMaker is stored in hours, minutes, and seconds, like so: HH:MM:SS. Sorting is based on a typical 24-hour clock.
• Timestamp—A timestamp is a tool generally used by database developers to identify exactly when a record was created or modified. It combines a date with a time and looks like “6/28/2008 2:00 AM.” For the user, you might occasionally want to use a timestamp when performing a find.

• Container—Container fields hold just about any binary information, be it an image, a movie, a PDF document, a Word document, or a file archive. You cannot use these fields for sorting purposes. Container fields are capable of holding files of up to 4GB in size, making it possible to use FileMaker Pro for managing all sorts of digital assets.

  Data entry for container fields is slightly different from other types: You need to either paste a file or image into the field or use the Insert menu.

• Calculation—A calculation field stores the result of a formula, which might be based on other fields or related information in your system. The resultant data is assigned a type so that one can return a date, time, and so on. It’s even possible for a calculation field to return container (binary) data.

  Calculations can also format data: From FileMaker Pro’s standpoint, there is no difference between a calculation that adds two fields and one that rounds a number to two decimal places and then turns the result red. You will find out more about this in the chapters about layouts and about sharing FileMaker Pro databases.

  NOTE

  

  The data in calculation fields is not modifiable by an end user; you can, however, access calculation fields for performing finds, sorts, and so on.

• Summary—Summary fields are similar to calculations, but they return information from your found set, or current group, of records. A summary field performing a Total operation, for example, totals a field across your current set of records. Other functions include averaging, totals, maximum, and minimum.

TIP

Layouts have front-to-back ordering of elements. Mouse clicks are handled by the frontmost object underneath the mouse. If you place a field that is not editable on top of a field that is editable, you can often provide very intuitive and sophisticated interfaces without troubling the user.

For example, if you place an editable phone number field on a layout, you can create a calculation field of exactly the same size and shape on top of it and specify that the calculation field is not editable. Clicking the calculation field does nothing; the mouse click passes through to the next object that accepts mouse clicks at that spot—the editable phone number field. The user can enter an unformatted phone number; then, when another field is selected, the calculation is performed, adding punctuation to the phone number, and it appears that the phone number field itself has been formatted. Actually, the raw phone number field is simply obscured by the formatted phone number created by the calculation.

Saving and Retrieving Information in Container Fields

Container fields work differently than other fields. You cannot type data into them; rather, you have to insert whatever file or media you want to store or display in them.

Note that a container field can do more than just store documents. For many image types, it can display the image within FileMaker; for many sound types, it can play the sound within FileMaker; and for QuickTime movies, it can allow users to play the files. Whether you store something as a document or as a media type that FileMaker can play depends on how you save the information to the container field. There are three general ways to store a file or media in a container field:

• Paste—You can place an image or a document on your Clipboard and simply paste it into a container field. FileMaker makes its best guess as to what kind of information is on your Clipboard and either stores a document or displays an image, a sound, or a QuickTime movie.
• Insert—Using the Insert menu, you can choose from among Picture, QuickTime (movie), Sound, and File. If you choose from the first three, FileMaker displays the media in question. If you choose File, FileMaker loads a document.
• Import—Under the File menu is the Import Records menu item from which you can further choose to import a file or a folder. If you choose to import from a folder, you can point FileMaker to a directory of images or files and load them into a container field. You can also import container data directly from other FileMaker files.

In both the case of inserting a single media file and the case of importing many, you have the choice of inserting only a reference to the file or of inserting the document itself. In the case that you insert a document itself, that document is physically stored in FileMaker and is accessible by all users. They can select the container field in question and choose Export Field Contents from either the Edit menu or the contextual menu available from the field itself. In addition, as you see in Figure 2.22, you have the option to compress a file that you are inserting.

Figure 2.22. Insert files and (optionally) compress them.

If you choose instead to store only a reference to the file, the file is stored physically elsewhere—for example, on a shared hard disk. To have access to the file, users must have access to the same shared directory on which the actual file sits. In this case, you are performing the same sort of task as saving a shortcut or an alias to the file: It remains on whatever storage device you found it.

The benefit of leaving documents on an external storage device and storing only references within FileMaker is that these documents require far less space within FileMaker for storage. Storing images and other files outside of the database itself is a common strategy used by efficient database management systems including FileMaker.

• See “Container,” p. 89, to see how you can manage external storage and other settings for files stored in container fields. (This feature was implemented in FileMaker Pro 12.)

Global Storage

Field data in your database generally pertains to a specific, individual record. The baseball team field for your San Francisco record holds the data “The Giants,” whereas for Chicago, it’s “The Cubs.” In some cases, however, a developer opts to define a field as globally stored. Developers often use a shorthand, globals, to describe these sorts of fields. The value in that field is constant throughout the database, regardless of which record is currently under inspection. Some common examples might be fiscal year start and end dates, your company name, report headers, or a fixed commission rate. As a user, you might not always be able to tell which fields in your database are defined to store global values and which are record specific.

An important point to keep in mind about global fields is that their behavior varies depending on how you’re hosting a database. If you’re using a database on your own local machine, with sharing set to single user, all global data is preserved from session to session. In other words, the next time you open the database, your global details remain from the last time you worked with the system.

If you’re working with a database hosted on a server, all global information is session specific. It might contain default values, but if you change some data in a global field, other users of the system do not see that change, nor is it preserved for the next time you use the database. If a developer has added global storage to a field in your system, it is quite likely that there are routines to manage what information it holds when necessary.

NOTE

Before the introduction of script parameters and script variables, it was impossible to create certain types of scripts without the use of global fields. As a result, older FileMaker Pro databases use global fields more often than modern ones.

Data Validation

Data integrity is one of the primary concerns of any database developer or of the team using a given system. If duplicate records appear where they should not, misspellings and typos plague your database, or worse yet the wrong data is entered into the wrong fields, your system will soon become unreliable. For example, if you run a monthly income report, but in a few of your transaction records someone has entered a date value where in fact a transaction amount belongs, your monthly totals will be incorrect.

FileMaker Pro—or any application, for that matter—cannot read users’ minds and fully safeguard against bad data, but developers do have a wide range of tools for validating information as it is entered. If your organization can come up with a business rule for validation, a developer can apply that rule to a given field or fields. Consider the following examples:

• Transaction amounts can be only positive numbers, can have only two decimal places, and cannot exceed 100,000.
• Employee hire dates may be only equal to or later than 1/1/2001.
• Data in a given field must match established values in a status value list containing the values open, closed, and on hold. The field will not accept any other status descriptions.
• Company names in the database must be unique.

Understanding that these rules are in place will help you understand the underpinnings of your database application. When a validation check occurs, the system might prompt you with an appropriate message (see Figure 2.23).

Figure 2.23. This is an example of a default validation message. If you choose Revert Record, whatever data you’ve entered into the field reverts to the state it had before you started editing.

In addition to the default dialog shown in Figure 2.23, developers can create their own custom text, as shown in Figure 2.24.

Figure 2.24. This is an example of a customized validation message.

If you choose Yes rather than Revert Record, your data is accepted as is and overrides the validation requirement. In some cases, you might not have the option of posting an override, and the Revert Record button will not be shown.

• To explore additional thoughts on addressing data problems, see “Data Integrity” in the “Troubleshooting” section at the end of this chapter.

CAUTION

Never, ever, under any circumstances, no matter what happens, use data to describe data conditions. Values of 0, 99, and –1 are values, not shortcuts for data conditions. You can use validation rules to prevent the storage of invalid data, and having done so, you can rely on the fact that the data is data. If you need to store imperfect data, consider using pairs of fields: as-entered data (which may be invalid) and validated data (which is always valid if it exists). FileMaker Pro correctly handles missing data (empty fields); anything other than valid data or missing data belongs elsewhere in the database.

Millions of dollars were spent at the end of the twentieth century tracking down what came to be known as the Y2K problem, much of which arose from the fact that programmers decades earlier assumed that it was safe to use 00 to indicate missing data for a year. The fact that 00 in the peculiar arithmetic of two-digit years was the result of 99 + 1 did not occur to many people until it was necessary to review every line of code in critical applications to see whether this had happened.