Working with Fields
| < Day Day Up > |
| Every table in any database ”FileMaker Pro or otherwise ”is a collection of information stored in fields (or columns , if you're familiar with that terminology.) It is by storing like information in appropriate fields that a database is given meaning. For example, by entering "124 Main Street" in a field called Address, we've identified what "124 Main Street" is. In the case of a street address, it's fairly easy to identify without a field definition, but what about "912.5" all on its own? That could be a price, a number of units, a chapter heading, or a thousand other things. When you place that number into a named column or field, your data becomes meaningful. If "912.5" sat in a field named Temperature, you'd likely conclude that such is pretty darn hot. Conversely, if it sat in a Kilobytes Available field, you'd look to be buying a new hard drive. Keep this ultimate goal of imparting meaning in mind as you create and name fields, and assign appropriate data types to them. Field Naming ConventionsOne of the nice things about FileMaker Pro development is the freedom developers have in naming fields. (FileMaker Pro is not unique in allowing developers field naming freedom, by the way.) That freedom also, unfortunately , gives rise to confusion and arbitrary naming conventions. "Name_xTJm2" may mean something to someone, or "Name" might also, but both examples ”the overly specific and the overly general ”require a strong familiarity with a given system. If you ever return to a database months after building it, odds are you will have forgotten your clever abbreviations. We encourage you to take advantage of FileMaker's allowance for long field names of up to 100 characters . Use full text names (like "Street Address line1"), avoid abbreviations (or if you use them be sure to provide an obvious key!), and try to group things logically. Here's an example of what we'd consider a fairly reasonable approach to naming fields:
These fields are quite simple to identify and are neatly grouped together when sorted alphabetically . This isn't such a big deal for small databases, but if you ever work on a large database, with multiple developers, a well established naming convention is vital . Right from day one we encourage you to adopt good programming habits. Another common approach many developers use includes abbreviations for data types. Often it's handy to know the data type of a given field when working with it without having to refer to the Define Database dialog. (Here we've used "t" for text, "n" for number, and "c" for calculation):
We'll cover indexing later in the chapter, but some developers also note whether a field is indexed or not (x for indexed, n for unindexed):
Some naming conventions also break out a division between data fields and what are commonly referred to as developer fields ”those fields that one needs only to make one's FileMaker Pro solution work. If you ever went to import your database wholesale into another system, these fields would be left behind. Here we have two abbreviations: k for key (or match field), and z (so that it sorts to the bottom of the list) for developer utility fields.
Finally, here's a real example from a database we recently were hired to modify (used with permission and good humor!):
We're sure we've belabored the point, but this database was difficult to modify not because it was complex, but because it was hard to read. As in all things, a little planning goes a long way.
There are some restrictions to field naming in FileMaker Pro: A field name must be unique and must be less than 100 characters. You can opt to use special characters, numbers , spaces, even the names of functions, but we recommend against using them. If you use: ,(comma), +, -, *, /, ^, &, =, We recommend strongly that you name fields without using special characters, the names of functions, or operators (AND, OR, NOT, XOR, TRUE, FALSE). The same is true for fields that begin with a space, a period, or a number: You'll have to contort your calculations to deal with them. Don't use them. Begin each field with a standard alphabetical letter or at least an underscore . Adding Field Comments
Creating New FieldsTo create fields in FileMaker Pro, you need to enter some text in the Field Name area of the Define Database dialog and click Create. One important aspect to databases to keep in mind is that it's important to establish a discrete field for each bit of information you want to store. If you create a field called Contact Information and cram an entire address and set of phone numbers into it, technically it will work fine, but if it ever comes time to export that information, sort by area code, or run a report by city, you won't be able to cull the information you want from the field without suffering from a good headache . |
For more information on using databases on the Web, 
, >, <, (, ), ", ;(semicolon), :(colon), ::(double colon relationship indicator), you need to enclose such special characters with a $() in calculation formulas to have them interpreted as field names. For example, the calculation $(Tax,special) returns the value of a field named Tax,special . 
| < Day Day Up > |
