AnsweredAssumed Answered

Layouts based on subsets of tables

Question asked by nihmbrisby on Jun 28, 2014
Latest reply on Jun 29, 2014 by nihmbrisby


Layouts based on subsets of tables



     I’m looking for a way to base layouts on subsets of tables.  I’m wondering if it’s good enough for my purposes to forget ‘sub-sets’ and simply restrict navigation so that one can’t move from records of one subset to records of another without first switching layouts.



     In my database I have thus far considered “contacts” and “authors” as separate entities with separate tables.  Authors create works that are bought/sold/traded/owned/advised on/etc… by contacts. 

     However, I’ve always had a sneaking suspicion that this was problematic, and that in fact contacts and authors are the same entities (each being a subset of a larger group, say ‘people’).  This suspicion has been borne out by many issues, principal being the fact that contacts and authors are both capable of fulfilling the same roles in transactions.  So, when I select a buyer on a transaction- I’d like to be able to select/find from a list/portal of both contacts and (some) authors.  Also, it’s clear that a single person may have an author record AND a contact record in such a way that may be confusing for the end user.

     On the other hand, I must have one layout based on contacts and another layout based on authors.  Furthermore it would be ridiculous for some authors (Dickens, Shakespeare) to show up in the contacts layout.  Neither the trigger-found-set nor the record level access solutions I’ve read about appeal to me for various reasons.  I don’t know another solution, but then again it may be that I’m searching for a solution to the proverbial non-existent problem.  Perhaps they don’t need to be separated at all.

     This is due in part to my approach to user navigation.  One of the first things that struck me when I was introduced to filemaker was the pointlessness (outside of found sets) of the little bar in the upper left hand corner with the number of records and the pie chart.  It always sort of drew my eye despite having no functionality outside of found sets.  Unless I’m missing something, the sort order outside of found sets is always date of creation.  In all my applications, this is meaningless distinction (ie there would never be a situation where the end user would navigate from one contact (or author) to another base on creation date).

     I’ve always planned on not displaying this bar (and then just recreating a less prominent version on my layout.)  However if I *only* display navigation arrows (and # of found records and whatever else) within found sets & all finds from authors (or contacts as the case may be) are restrained to authors (or contacts) via an additional search criteria to all searches, then it seems to me that authors will always be displayed with the authors layout (and contacts with their layout) and that one will never be able to ‘arrive at’ a contact while in the author layout (and vice versa).  In this scenario the distinctions between contacts and authors would be based on a field (and Is_Author field and, amongst authors, an Is_Historical field.)

     Will this work?  Is there a better solution?