If you aren’t familiar with the session model in FileMaker, this blog post and video by Todd Geist is a great introduction (one more bonus: he integrates the Selector model into the session model in this video).
The session model is all about tightly controlling the data and views displayed to the end user. It does this by adding a Table Occurrence (T.O.) in front of all the other T.O.’s, effectively making all the data tables ‘children’ tables. Think of an invoice system, for example. The invoice itself is displayed on a layout based on the layout table. Invoice line items are a related ‘child’ table that displays only the line items related to that invoice.
The session model is similar, but the developer controls what is seen and not seen. The down side to this? You need to build the find, display, and modify functionality for the end user with scripts and layouts. The plus side? The end user’s experience is tightly controlled and the chances of making mistakes are lessened considerably. It’s also great for dashboards and for showing data in more than one context. Geist describes another benefit as for WebDirect implementation, too:
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.
As with any tool in the tool chest, there are times it is the best for the job, and times where it does not work well, if at all. When would you use it?