3 Replies Latest reply on Aug 13, 2017 6:19 PM by philmodjunk

    Amalgamating data structures.

    PaulSeabright

      I have a copy of a live solution, consisting of a structure and a data file AKA The Separation Model.

       

      I have written another module for this that uses the data file as the basis, and added fields to existing tables and new tables were necessary - a fork if you will of the original.

       

      I want to combine the structure of the original data file, and the fork (the data doesn't matter at this stage - its all test data).  I thought I could achieve this by first making sure that the original data file had all of the tables, and fields (and the names were the same) as the forked data file.  Then in the forked structure file, point all the T.O's to the original data file.

       

      At this point I can almost hear the groans from the seasoned developers out there!

       

      Pointing the TO's to the original data file went reasonably well, with a few relationships that needed to be recreated.

       

      However, I was not expecting the 'Field Missing' errors on layouts and more concerning, in scripts...

       

      My question is, what causes this - why does it happen?

       

      and, is there a better way to achieve the goal of unifying the two data structures?

       

      Many thanks for your help.

        • 1. Re: Amalgamating data structures.
          philmodjunk

          File maker does not reference fields by their name except in very specific cases. Each time that you create a new field, table or table occurrence, that newly created object is assigned a unique ID. FileMaker uses those IDs to reference the data. Most such errors occur when the front end is set to reference a field using an ID that does not exist in the back end file.

           

          Note that if you add 5 fields to a back end file's table, then open a different copy of the same back end and make the same changes, it's very, very easy to get some fields that don't have exactly the same internal ID's. Then a "Front end" file that was correctly referencing data with one of the two back end files can get these errors with the other back end file if it is used in place of the first.

          1 of 1 people found this helpful
          • 2. Re: Amalgamating data structures.
            PaulSeabright

            Thanks Phil.

             

            What would be your advice for the future when needing to adding another 'module' to an existing solution?

             

            For example, one that has an 'Orders' module that has tables for parts, customers, addresses orders and order line items. An additional iPad based module is required to record jobs and services that would share parts customers and addresses, but would also have tables for jobs and  work history.

            • 3. Re: Amalgamating data structures.
              philmodjunk

              Keep just one version of the back end in place. That back end might consist of several files, but manage them to be one version.

               

              Then use that one one version as the context for any updates to the design of your front end files.