Some Confusion About 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). 

I have seen some developers describe the separation model as a front end file with a table that has a single record with nothing but global fields used to filter a relationship to a back end file that has the data table. Many people describe the front end record as a header and the related data as the body (akin to what you see in standard list view).

I don’t agree with using the term of Separation Model to describe that process but that process does use a separation method. This particular technique is an old school method (pre-FileMaker 7) of using a separation method that isn’t needed with all the power and flexibility that was introduced with FileMaker 7. Now, if you are working with a solution that uses this system from a converted pre FileMaker 7 solution, I would suggest you take the opportunity to rework the solution to better harness the power a more modern version of FileMaker offers.

The idea of having a single record that can show a variety of related information based upon the tweaking of global fields is what most developers call a dashboard. Dashboards are a great design technique and can be used inside/outside a separation method. Dashboards are also often used in multiple file solutions in order to keep the workflow from moving from file to file.

In the old school method, you would need to go to the data file to perform tasks like batch updating of records. With FileMaker 7 (and above) that isn’t the case because of the magic of table occurrences.

Case in point, my InBizness product has a single record that shows multiple options of related data. The layout is designed for sales reps and they can see client information, to do lists, follow up tasks, invoicing history and much more. This is a single file solution, so it does NOT use the separation model. It however does meet most of the criteria I described in the opening paragraph.

All you need to do is create a table occurrence you want and then create the layout for it in that file using that reference. All GTRR actions can go to that layout and show all the related data from that file without having to go to that file.

A big reason to never leave the interface file for your scripting is the use of script variables. Although there are techniques to pass variable data within files, they are usually cumbersome and potentially unreliable.
=
More info about the author and FileMaker in general, contact me at info@dwaynewright.com.

© 2008 - 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.