3 Replies Latest reply on Nov 28, 2011 12:40 PM by LaRetta_1

    Multiple Layouts

    PlatinumDigital

      Title

      Multiple Layouts

      Post

      I have only recently started using FileMaker professionally and am completely in love with it. I can't believe how easy it is to use. I've really only been on it for two days and am already further along than I've been in two years.

      My problem is this. I have multiple databases that all need to link together at some point and thought that with a recommendation from some people that I may be better off having them all in the one file under different layouts. Could someone please recommend if this would be the best approach as it would be easier to fix it all now rather than later when I have another 5 odd databases.

      I've included a screen-grab of 4 screens as I have them as separate databases currently and the flow order from screen to screen. My aim very simply is to link the details of the 'Contacts' (people) back to be listed at the bottom of the 'Clients' (company) page. As I currently don't know enough about FileMaker; Is it going to cause problems later on if all these databases are in one file as different layouts or will it make it even more simplified.

      I look forward to your opinions.

      Platinum_%5BFileMaker%5D.png

        • 1. Re: Multiple Layouts
          LaRetta_1

          Hi Platinum Digital,

          Showing your UI in browse mode doesn't help us understand which fields are set up under which table; regardless, it is too small for me to read, sorry.  Here are some thoughts to help you decide:

          If you have a Company which purchases from you and a Company which sells to you, they are both companies and should belong in the same table with a field Type to designate 'seller' or 'customer'.  If all companies only have one employee (contact), the employee can be in the company table but that is rarely the case.

          One company can have multiple contacts so these contacts are the many side to the one company, known as 1:n.  This means that contacts should have their own table and also have a field called CompanyID which holds the unique ID from the Company table.  If one contact can have multiple phone numbers then you need a Numbers table with a Type field to specify whether the number is: Home, Office, Beach House, Warehouse, Garage, Fax Number etc.

          If you ever find yourself creating multiple fields which contain similar information, stop yourself short.  An example, when we see this in someone's file, we know it is wrong:

          Sales2009
          Sales2010
          Sales2011

          ... or

          ProductPurchased01
          ProductPurchased02

          If you wish to upload your file somewhere, we would be happy to review it and make suggestions.  If you wish to message us privately, we can review the file in private but it is preferred to keep the discussions on this forum, if possible so others reading this thread can know how it was solved.  If you can not upload your file (you can clone it without records), then I suggest you post a screen shot of your relational graph.  :-)

          • 2. Re: Multiple Layouts
            philmodjunk

            While developers can readily argue both sides of the issue as to whether or not tables should or not be defined in a single file, most new users will find that putting them all in one file makes developing and managing the database simpler to do as it avoids a number of issues with multiple file solutions.

            Once you get things working to your satisfaction, it's not terribly difficult to transition your database into a Convert to Seperation Model to make deploying updates to your file easier to manage.

            • 3. Re: Multiple Layouts
              LaRetta_1

              The term databases does not apply to FileMaker. FileMaker has files which can have multiple tables within it.  Some consider tables to be databases which would be more accurate.

              "thought that with a recommendation from some people that I may be better off having them all in the one file under different layouts. "

              Whether using one file or many, ALL data can be viewed and handled within one file on various layouts.  I see the question more about how to split up the data into various tables within the file.  I think we need further clarification on what is being asked.