2 Replies Latest reply on Oct 11, 2013 9:17 AM by adamtylerlynch@gmail.com

    Versioning and Updating

    adamtylerlynch@gmail.com

      Title

      Versioning and Updating

      Post

           I've deployed a FileMaker solution to a clients business. I have been working on "version 2" that includes new features.

           How do I migrate those changes (table changes, relationship changes, scripts, custom functions) into their system while preserving their data? I come from a enterprise development background where data was abstracted from the application. Maybe its something I am just over looking, but how do I migrate my changes into their system? Is there a best practice defined for this?

           I hate the idea of developing against production (making changes in their system as they use it). Can someone shed some light on this?

            

        • 1. Re: Versioning and Updating
          philmodjunk

               Basic method:

               Deliver a clone (empty copy) of your new version to the client. Take the database down to stop ongoing modification of the data until you are done. Use Import Records to copy all data from the current file into the new file. Update any auto-entered serial number fields to make sure that their next serial value settings will not generate duplicate values.

               That's a lot of work to do manually and a mistake that fails to update all data or that leaves a serial number auto-enter setting un-updated can be catastrophic.

               Enhanced Method 1:

               Create a script that imports the records and updates all the serial number fields. It's possible to set this up so that the user clicks a button in the new version, selects the original file in the dialog and then the script does the rest for them. You still have "take down" the file so that you don't get changes taking place during the update but at least the scripted method gets the job done much more quickly.

               Before sending this update to the client, test the update script very carefully to make sure that it works. One key detail is that you need to do a Show All Records on each table prior to importing to make sure that all records are imported. A script in the original copy can be run to loop through all layouts doing a show all as a "prep" for this update script.

               Enhanced Method 2:

               You can modify the design of your solution to split the file into two parts, an interface file and an data file. In the scenario you have described here, there's no advantage for this particular update as you indicate that you have modified tables and fields, but many updates are only interface updates--scripts, layouts etc are updated without changing table or field definitions. In those cases, you can simply replace the old interface file with the new and not have to import any data.

               This is often referred to as the Convert to Seperation Model.

          • 2. Re: Versioning and Updating
            adamtylerlynch@gmail.com

                 PhilModJunk, 

                     Thanks for the information. I'll probably go with a blank database and an "import" function to import the existing data. I've only added columns so the data storage is fully backwards compatible.

                  

                 Thanks again,