< Day Day Up > |
One of the most important aspects of understanding FileMaker Pro is understanding field types, how they're different from one another, and how to use them effectively. Simply stated, field types identify what kind of information each field of your database is expected to hold. A person's name is text, the dollar amount for a transaction is a number, a birthday is a date, and so on. Generally it should be quite clear to you what each needs to be. Field types determine what types of operations can be performed on a given field, what information a field can accept, and the rules by which a field is sorted. It's the combination of a proper identifying field name and a data type definition that gives a database its context and meaning. TextText fields are the most freeform of the field types. Users can enter any range of information in them, including carriage returns, and there's no expectation of what form or sort of information a text field will hold. The only requirement is that it be text ”in other words, you can't place a picture in a text field. A text field can store up to 2GB of information, limited by RAM and hard drive space, of course, and indexes up to approximately 100 characters , depending on what language you're using. We'll cover indexing in more depth later in the chapter. For now, simply remember that each field type has different limits and approaches on indexing. NumberNumber fields can store values from 10 -400 up to 10 400 , and negative values in the same range. FileMaker Pro indexes the first 400 significant digits ( numbers , decimal points, or signs) of a number field, ignoring letters and other symbols. Number fields can accept text (though not carriage returns), but any text in a numeric field is ignored. FileMaker interprets "12ax3" as 123 if you enter it into a numeric field, for example. Something to keep in mind with FileMaker Pro: A number field can be expressed as a Boolean. A Boolean value is either true or false, and is often used to test the condition of something. A zero or null value is false; any other data is true. You will often run across number fields being used in such a manner. The primary distinction between a number and text field lies in how they're sorted: a text field sorts 1, 10, 2, 20, 3, 4, 5, whereas a number field sorts 1, 2, 3, 4, 5, 10, 20. DateDate fields accept Gregorian calendar dates only. FileMaker Pro honors whatever date standard your country follows by taking the standard your operating system uses at the time a new file is created. Date formats ”the order of year, month, and day ”are common for a given file. Although it's possible to change the way dates are displayed, it is this basic ordering that is fixed at the time of file creation. Dates in FileMaker Pro are internally stored as the number of days since 01/01/0001. January 1, 2004, for instance, is 731581. If you need to compare dates or perform any functions on them, remember that behind the scenes they're really just numbers. This feature is actually quite handy. To switch a date to a week prior, all you need to do is subtract seven. Date fields can store values from January 1, 0001 to December 31, 4000.
TimeTime fields hold HH:MM:SS.ddd information. Notice that a decimal may be added to the end. Also useful: If a user enters "25:00," FileMaker Pro rightly interprets such as 1:00 a.m. 99:30 becomes 3:30 a.m. The clock simply keeps rolling over. This behavior is useful when you need to add, say, 30 hours to a time, and don't want to be bothered with calculating what hour that becomes. Likewise, if you are doing data entry in a time tracking system and don't want to create two entries for a case where you worked from 2:00 p.m. until 2:00 a.m. on Monday (really Tuesday), entering 26:00 in your system rightly calculates to 12 hours. As in dates, FileMaker Pro stores time internally as the number of seconds from 12:00:00 on the current day. "1" is 12:00:01, and "43200" is 12:00 p.m. Likewise, your time format is established during the creation of the file, based on system OS settings. The maximum time value you can store in FileMaker Pro is 2,147,483,647. That's a lot of time. TimestampTimestamp combines date and time information. It appears as a field with both date and time values, separated by a space: 1/1/2004 12:00:00. As in date and time formats, timestamps are stored also as numbers: the count of seconds from 1/1/0001 00:00:00. Be prepared to work with large numbers when using this field type. Timestamps are an important aid to interoperability with other databases (such as those powered by the SQL language), which often store date and time information in a single timestamp field. The maximum value of a timestamp is 12/31/4000 11:59:59.999999 p.m. or 126,227,764,799.999999 seconds. ContainerContainer fields are different from the four above: They store binary information. Information, such as it is, is often inserted into them rather than being entered manually (you can copy and paste). You can place any sort of digital document in your database, limited again by the practical limits of your computer hardware, up to 4GB. Container fields also support displaying/playing three native types of media: pictures, QuickTime movies, and sounds. Refer to the FileMaker help system for supported formats, but most common image formats are included as well as some you won't expect. For example, by using QuickTime, it's possible to display and play a Macromedia Flash 5 .swf file. Last, on Windows, a wide range of OLE objects are supported, including Microsoft Excel documents, PDF, and more. One important thing to remember about using container fields: You can store either the file or media in FileMaker itself ”requiring disk space ”or simply store the path reference to the file. If you choose to store just a reference to the file, FileMaker Pro, somewhat like a Web browser, displays the image or file icon as necessary, but does not hold the actual document itself. A nice feature of storing references is that you can then double-click documents in your container fields to launch them in your operating system. CAUTION Keep in mind that if you move the source document, the FileMaker Pro reference remains but is no longer valid. CalculationCalculation fields evaluate formulas and display the requisite results. When you create a calculation field, the Specify Calculation dialog opens. Be sure to refer to FileMaker Pros online help or this book's Appendix B, "Calculation Function Reference," p. 807 , for a complete list of functions. The features of the Specify Calculation dialog box include
Examples of calculations include
Calculations are fundamental to FileMaker programming, and it's worth your while to master them fully. For more detail on Calculations, see Chapter 8, "Getting Started with Calculations," p. 213 , Chapter 14, "Specialized Calculation Functions," p. 381 , and Appendix B, "Calculation Function Reference," p. 807 .
SummarySummary fields allow you to evaluate information across a found set of records. Sum, Average, Max, Min, and Count are among the summaries you can establish. Don't forget that they apply to found sets: Change your found set, and the result changes. For example, say you have a table called Transaction, which contains Tranaction_Date and Transaction_Amount fields. You can then define and place on a layout a summary field to total the Transaction_Amount field. The summary field adds the values of the Transaction_Amount field for whatever set of records is currently active. If you perform a find, by date, on 10/1/2003 “10/31/2003, your found set will be all the transactions for the month of October and the summary field would show just the aggregate monthly transaction amount. Perform a different find request and your total changes, reflecting the aggregate of the new found set. Table 3.1 contains a list of Summary field functions. Table 3.1. Summary Field Functions
When you create a summary field, the Options for Summary Fields dialog opens, prompting you to choose the function you want to use and the field for which you want a summary (see Figure 3.3). Figure 3.3. Summary fields are useful for performing functions across sets of records, but use them with care. They can slow down the time it takes to load any given layout.
It's generally a good idea to place Summary fields on their own layouts so that a user deliberately chooses to have them evaluate a found set. |
< Day Day Up > |