Why Try The FileMaker Separation Model?

From Dwayne Wright PMP
Certified FileMaker Developer

WEB: www.dwaynewright.com
EMAIL: info@dwaynewright.com
TWITTER: dwaynewright
YOUTUBE: FileMakerThoughts

Please Note: If you are viewing this page in a news feeder, the images may get munged up a bit. For the best experience, please visit the journal directly by clicking (here). 

The separation model is a design process where you have all the tables that contain data in one file and all the user experience programming in another file. By expert use of relationship design and scripting, you deliver the experience to the customer that both files are one engine.

So why go to such an extreme design method when the single FileMaker file implementation is so popular and powerful? Well, it was born out of one simple question. How do I continue to develop a clients solution while my client is using the current solution version?

Well, using the above description of the separation model, you may be able to do the core of your development work in the file that DOES NOT contain any of the solutions data. When you upload your new version, you leave the data file untouched and the client gets the benefits of your recent changes.

As a developer considering a separation model implementation, you might have questions such as ...

  • What is considered best practice for planning, building and testing a separation model implementation?
  • What is the fastest and easiest method to make the change to the separation model without having to redo too much work?

Well, the first thing I would recommend before considering the move towards a separation model is to clean up and organize your existing database first. The primary target for clean up should be your relationship graph. If it is not in anchor / buoy format, consider moving towards that implementation. Make sure all your layouts are organized by the entity they use and I would recommend the same thing for your scripts. The reason for this is quite simple ...

One of the fastest and easiest ways to take a single file solution to the separation model is to duplicate the file, wire them up to each other based upon their role (one file for data and one file for presentation) and delete what you don’t need from each. More about this in later postings.

Here is a link on the Six Fried Rice Blog. I think it does an excellent job of laying out the foundations for understanding the key concepts behind the separation model technique.


It is always a good idea to get information about important techniques such as the separation model from as many sources as you can. I wouldn’t put a “silver bullet” designation on the separation technique as this post suggests. The chances that any significant design changes your client will need reside only in the UI file is ... slim. In my mind, that isn’t the significant advantage of the separation model.

I’ve done a half dozen or so separation models and they vary from the classic version to the enhanced version. A classic version can be ultimate two file solution described in the posting. An enhanced version can be where you have multiple data files and one UI file. The multiple data files can be organized so that a single file holds all the client related records, all the invoice / inventory records or all the possible join tables. I find that if I have a solution with a large amount of join tables, it is not a bad idea to create a single file to contain them. Once created, join tables normally don’t change much in the way of fields, scripts or relationships.

More info about the author and FileMaker in general, contact me at info@dwaynewright.com.

© 2011 - Dwayne Wright - dwaynewright.com

The material on this document is offered AS IS. There is NO REPRESENTATION OR WARRANTY, expressed or implied, nor does any other contributor to this document. WARRANTIES OF MERCHANT ABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE EXPRESSLY DISCLAIMED. Consequential and incidental damages are expressly excluded. FileMaker Pro is the registered trademark of FileMaker Inc.