3 Replies Latest reply on Oct 25, 2010 12:25 PM by FentonJones

    How do I add new features to a runtime FM app

    MarkSchwartz

      Title

      How do I add new features to a runtime FM app

      Post

      I'm a newby with big dreams.  I'm thinking of a distributed  runtime FM app that needs to be upgraded from time to time...new features & bug fixes.  It appears that the data is tightly integrated with the logic in FM and I like to know the easiest way to update Layouts & scripts without changing my tables, relationships, and existing data (unless of course I choose to do so.)

      Thanks in advance for your help.

      Mark

        • 1. Re: How do I add new features to a runtime FM app
          philmodjunk

          Split your solution into two files. File 1 holds all data-source tables and file 2 has all layouts, script etc. The Relationship graph for File 2 refers to the data tables in File 1 via external data source references. Now users can replace old copies fo File 2 with new versions and their data staysp put in File 1.

          You can also write scripts that automate moving data from the old file to the new when you do have to update the data file.

          • 2. Re: How do I add new features to a runtime FM app
            MarkSchwartz

            So I create all of my tables in File 1.  No tables in File 2.  Use the Relationship graph in File 2 to display the tables in File 1 and then I can build layouts and scripts in file 2 relating to the tables in File 1.  Smooth.

            Thanks,

            Mark

            • 3. Re: How do I add new features to a runtime FM app
              FentonJones

              You will still need some "extra" relationships (besides the basics) in File 1, for relational calculations. Fortunately, because these are calculations not actual data, you can add them later.* In fact, you can add fields to File 1 later also. Because a new field does not usually have data at first, so no "import of existing data" is needed. 

              You should still do Phil's 2nd suggestion though, a routine to Import all tables' records into a (good) Clone (including updating the "next" serial number in every relevant table). There is one situation where an Import is critically needed. That is if the original file crashes badly. If you have access to the file, you should import all data to a clean Clone. Then you're good to go.

              * If for some reason you are working on 2 separate copies of a "data" file, it is critical that the Field IDs of new fields line up. That is what FileMaker uses internally, in scripts, etc.. There is a way to see what the "next" Field ID of a table is going to be, so it is possible to check.