This chapter is from the book
This chapter is from the book
This chapter is from the book
Troubleshooting
Mismatched Data Types
My data isn't sorting properly. Where should I look first to diagnose the problem?
One of the most common bugs you'll run into in FileMaker Pro is confusion stemming from mismatched data types. If your users are entering text data into a field you have defined as numeric, you're bound to get unexpected results, and sorting will be unpredictable. Check your field types when your data appears to be misbehaving.
Mismatched Calculation Results
One of my date calculations looks like an integer. What's going on?
Some of the more subtle extensions of the data type problem are calculation fields. Note that their result is both the determination of their formula and a data type you set at the bottom of the Specify Calculation dialog. If you're working with dates and return a number, for example, you'll get an entirely valid calculation that will look nothing like "12/25/2003."
Problematic Field Names
My web programmers are complaining about my field names in FileMaker Pro, and that I keep changing them. What should I consider when naming fields?
Some other systems are not as flexible as FileMaker Pro—this is especially true for URLs and the Web. Spend some time with Chapters 21 and 23 if you ever plan to publish your database to the Web. FileMaker Pro breeds a certain freedom when it comes to changing field names as the need arises, but you'll send your XSLT programmer into fits every time you do.
Also be sure to check the restrictions of various SQL databases in your organization. In the case that you need to interoperate with them, you might need to have your field names conform to stricter naming standards.
You'll be safe if you never use spaces or special characters and start each field with a letter of the alphabet or an underscore.
Validation Traps
My field validation seems to have gone haywire. I defined a field that now simply throws up one error message after another. What's the problem?
At the end of the day, field validation is only a helpful bank of sandbags against the storm of human interaction your database will suffer. And as in all aspects of your database, the first and worst human in the mix is the developer. Just as with any programming logic, carefully test your validation conditions. FileMaker Pro can't totally prevent you from illogically conflicting restrictions. For example, if you set a field to be unique and nonempty, but also prohibit modification in the auto-entry options, the first record you create will trap your system in an irresolvable conflict.
It's a good idea to leave the Allow User to Override During Data Entry option enabled while you're building a solution and turn it off only when you have completely tested the field in question.