I've been creating FileMaker databases and creating software for over 20 years, in that time I've picked up a trick or two to make creating (and perhaps more importantly, maintaining) your work fast and easier - Here are my top tips:
1. Start clean
It's always best to start with a new, fresh database. If you do want to use a file you've used previously it's best to keep an unused copy somewhere that you can then duplicate. Starting with a previously deployed solution may lead to corruption being accidentally incorporated into new work. If you need to bring in scripts and layouts, just copy and paste them.
2. Comment, comment and comment again. Comment your code - I can't say this enough. The script you write today may make perfect sense but when you come back in 2 years time you probably won't remember, especially if (as I do) you maintain dozens of different systems for different clients. In all our solutions we have a comment header which says:
- The purpose of the script - Who created it - When / Why / any parameters it requires - Notes, when it was last modified etc.
As you write your script explain clearly what you're doing at each step. If you change, make a new comment dating when and why you changed it. If it's a customer request, paste in the customer's comment in speech marks, so when your client complains something isn't right - you can trace who requested the change!
3. Add Version Control
Make a global field in your file which includes a version number and a date. Whenever you make a change, increment the version number and date, then add a comment in your starter script as to what you did (see above). If you need to revert your solution back to an older version or restore from a backup, you can make sure you've got the right version. There's nothing worse than trawling through 20 copies of the same database trying to work out which is the most recent.
4. Group your Primary Keys The most important field in any FileMaker table is your Primary Key. Group these together, we like to use underscores but it doesn't matter as long as you keep it consistent. In our systems a double underscore signifies a primary key and a single underscore is a foreign key. For example:
__ID
_AddressID
_ContactID
This means that if you sort alphabetically all your primary keys will appear at the top of the field listing.
5. Test & get feedback Test all your scripts yourself, but even better is to get someone else to test. Once you're sure you've got all the obvious bugs ironed out, show your client and get their feedback. Take detailed notes, send these to your client for reference and revise your system accordingly. Rinse and repeat until you've got it right. Thanks to your notes you now have a history of what was done and why, in case there are questions later.