Skip to end of metadata
Go to start of metadata

Welcome to the Best Practices section of this wiki. You'll find a list of possible best practices which you can use in your own FileMaker solutions in the left hand sidebar.

If you would like to propose a best practice then please visit the proposals section of this wiki.

  • No labels

4 Comments

  1. Anonymous

    I see you have a pre-hosting section but is there a pre-file section?  What I mean is ... I keep forgetting to uncheck smart quotes when I create a file and it ends up biting me later.  It would be good to have this in a list of standard things to do.

    1. Good idea. Something like a pre-building checklist. Things included may be stuff like...

      Prepare your default fields
      Choose to have fields auto-index or not
      Add your script documentation template scripts with headers, etc.

  2. Anonymous

    Greetings,

    I would like to discuss the best practices for "container objects" with respects to user data. 

    I have been using SuperContainer for years - and in doing so my practice regardless of data entity being used, I always have had ONE SuperContainer table that stored all the paths to the file. Any entity that needed to store documents, images etc. would get a table occurrence, and relationship to the container table. All actions for Create, Edit, Delete would be scripted to this table.

    With FileMaker 12 and Remote containers I would still imagine that it would be "best practice" to have this data type normalized. For the fact that if some un-inteneded deletions where to happen in the parent entity the child image file would remain. (barring any cascade delete on relationship) 

    Thus it makes it possible for any entity to have one or unlimited type of attachments vs having to create schema for specific document types. 

    I would be open to hear others view on this data type and a general set of standards regarding containers.

    Humbly

    Stephen Dolenski

     

     

    1. Can you explain any other reasons why you think having a dedicated table for containers should be a best practice? I don't find the possibility of having arbitrarily many "attachements" associated with a record a compelling reason to treat all container data this way; not all container data has an attachment relationship with the rest of a record. Regarding accidental deletions, isn't that what backups are for? If a record linking to a container gets deleted, is it really any easier to recover the connection to that data, especially if secure storage is turned on? Is it necessarily inappropriate to create schema for specific document types?

      Having a dedicated table for container data attachements to other records is a useful practice, but is it really a best practice, and compared to what?