(Thanks to Naomi Fujimoto, you can read this post in Japanese)

Way back before FileMaker 7, Colleen Hammersly from Data Waves, and Wendy King came up with something called the “FileMaker Separation Model”. Part of that model involved only displaying data through relationships from a central file/table.  This pattern came to be called the “Session Model”, and this video is an explanation of its key concepts and its pros and cons.

Tight Control

Since everything is displayed through relationships there is no way for the user to see or edit records that aren’t explicitly made available by the developer.  Typically the developer closes and locks the status area, and puts everything under script control.  The user never sees find mode or list view.  Although you can assert tight control without it, the FileMaker Session Model is tightly controlled by default.

No Obvious Base Table

Every Layout in a FileMaker system needs a base Table Occurrence (TO).  If you are building a Layout to view “Contacts” you can build it right on a Contacts TO.  But what if you are building a “Home” screen or a “Dashboard”?  What TO do you base it on?  The FileMaker Session Model provides a special utility table called “Session,” for this purpose.  The Session TO  becomes the base for all the layouts you need that don’t have an obvious one. It turns out to be great for “Home” and “Dashboard” kinds of views, because often the data for these types of screens comes from many different tables.

Slide Panels and Other UI Goodies

Sometimes you want to switch from a Contact to an Invoice and use the cool slide panel for the effect.  If both Contact and Invoice can be displayed on the same layout, this is easy.  You just switch panels and select the record you want to display by creating or activating a relationship to it.

Why not use the FileMaker Session Model?

It’s not perfect. You don’t get List View, or Find Mode.  A more subtle impact is that your FileMaker Script Triggers have less focus.  They are fired based on the Session record and not the related record you might want them to be responding to.  I typically only build a part of my interfaces this way for these reasons.

Let’s Get Technical

The Session Record has one main job. It is to make sure that it can’t get locked by other users or browser tabs in the case of WebDirect.  It does this by having a unique record for each connection that is made to the Database. I say “connection” because if you just do it based on account name you’ll have problems with WebDirect, since every browser Tab is a new Database Connection.  So the same user can open up many separate connections to the database. And you don’t want them to share the same record or they can lock each other out. Here is what a FileMaker Session Model graph might look like. ( click on  the images to zoom )

FileMaker Session Model

FileMaker Session Model Relationship Graph. Note the use of relationships to display all records

It can also be used to select the records displayed through relationships, as we are doing here, by setting key fields in the table. But it doesn’t have to.  You can use it along with the SELECTOR model, if you want to be modular. And really! who doesn’t want to be more “mod”?  Here is what that looks like. ( click on  the images to zoom )

FileMaker Session Model

Session Model used with the Selector Model

In this case, the SELECTOR model handles selecting records for display and SESSION handles making sure that a record is available for each connection to the DB to prevent record locking.

I prefer this way of keeping things as modular as possible. It fits with the ModularFileMaker.org philosophy.

Example Files

Both the files I used in the video are available for download, here.

Thanks for watching. 🙂