5 Replies Latest reply on Mar 13, 2014 10:56 PM by BMyers

    What do you know now that you wish you knew then?


      I am new to FileMaker, climbing the learning curve. I‘m not a pro, but I have some experience in databases and am building a new app to manage my projects, contacts, tasks, notes and documents in a business setting. Fairly standard stuff to all of you.


      Occasionally I have one of those ”doh” moments where I realize that something could have been so much easier if I had only known...


      It struck me that all of you pros have probably done the same thing. I thought it would make an interesting discussion thread. What do you know now that you wish you knew when you were starting with FMP? Is there a function, a technique, a trick, some great training materials?


      Or to put it another way, if you knew you were going to have amnesia tomorrow and had to start learning FMP again, what advice would you email to yourself today?

        • 1. Re: What do you know now that you wish you knew then?

          A few things leap out at me often as I maintain a system built by a smart guy who didn't really know FileMaker:

          1. There are often a number of ways to accomplish a given desired action, but the most obvious way is not always the best. Typical example: getting a value from one place to another in a script. The obvious way is Copy/Paste, but that puts you at the mercy of the user switching applications and copying something else. Instead, look at Set Variable (to capture the desired value) and Set Field (to get the value into the desired place).
          2. In Calculations, a nested If statement is murder to set up and debug. Instead, have a look at the Case calculation (it's similar in concept to the Select Case in Excel macros, but quite  different in syntax, so watch that one). If you can get your head around Case, the quality of your code will jump dramatically.
          3. Substitute, List and GetValue are all calculations I use regularly and particularly love for their usefulness and elegance. Read up on them in the Help, and have a think about how you will use them.
          4. Read up on and experiment with the "Go To Related Record" script step. It is absolute gold.
          5. There are some very useful techniques to be mined using the fact that a return-separated list in a field will provide multiple match keys for that record in a relationship.
          6. The Let statement construction is very helpful for creating more-readable code. You will thank yourself for using it when you come back a year later to adjust something.

          Feel free to ask for clarification or expansion on any of those. But they are a good start.

          • 2. Re: What do you know now that you wish you knew then?

            beware the checkbox, fear the table occurrance !! Always check the data.

            • 3. Re: What do you know now that you wish you knew then?

              The points on Rob's list are all excellent recommendations. Here are some others, in no particular order:


              1. DRY ( Don't Repeat Yourself, which obviously is the opposite of WET …): use script variables, Custom Functions, and Let().


              On that note: whenever possible, combine similar tables into one by using a Type/Category field. Trying to maintain ContactsNotes, TaskNotes, ProjectNotes and WhatNotNotes is no fun … (though developing for WAN and avoiding large related tables can be a good reason to go with several smaller tables …)


              2. Grasp the Relationship Graph, how TOs work, and the general notion of “context” in FileMaker; once you have that down, you will feel (and work) much more confidently, since almost everything else is based thereon.


              3. Use true Booleans in fields and variables – instead of text and Yes/No (Active/Inactive … etc) value lists, use a number field, a value list with just 1 and a checkbox.


              This will make the programmatic use of these fields much easier – in scripts: If [ not Accounts::active? ], or If [ $print? ], as well as in calculation fields: Sum ( Members::active? ) / Count ( Members::primaryKey ) * 100 – and on layouts you can use formatting options for number fields.


              4. Comment the non-trivial parts of your scripts (and calculations). You'll thank yourself for it.


              5. Don't use a $$ where a $ will do.


              6. Whenever you find yourself creating (and trying to use) fields like attribute1, attribute2 … attributeN – use related records instead.


              The more so when you have attributeA1, attributeA2 … attributeAN, AND attributeB1, attributeB2 … attributeBN, … etc. and try to bring all Ns together. Instead of having one table with many fields, have several tables with few(er) fields.


              7. Consider using tables/records instead of value lists (VLs) to encode your secondary business data; e.g. instead of a hard-coded “Status” VL, use a Status table. There you can add attributes like a chronological order to use in sorts, which would be very awkward to achieve with a mere value list.


              This also allows you to rename a Status without having to correct existing extries, and lets you use more interesting UI tools than checkboxes, radio buttons and lists, e.g. a portal.


              8. Avoid using repeating fields for your business data. Having said that, they make excellent tools for UI and dashboard purposes.


              Nerd Classifieds: “Must Love Lists!”

              • 4. Re: What do you know now that you wish you knew then?
                Stephen Huston

                To expand Rob's Rule #1 to something much more general:


                • There are multiple ways to do almost everything in FileMaker. So, if I've only thought of one way, I'm not yet ready to pick to best way. Figure out at least 2, preferably 3, ways to do something, then pick the one which will be best after considering long-term maintenance, scalability, and fast reporting.


                And comment everything which isn't self-commenting (i.e. a field named "LastName"), including field definitions, scripts, and calculations which use multiple functions. I can promise you that some bit of clever programming written 2 years earlier will come back and bite you once you forget why you wrote it just that way -- if you didn't comment it.

                • 5. Re: What do you know now that you wish you knew then?

                  What a great list of suggestions.  Thanks to everyone.  I'll take more if anyone has a tip to add.