9 Replies Latest reply on Nov 15, 2016 3:41 PM by Wicktor

    Suggestions for Solution Updates

    Wicktor

      Hello everyone,

      I would appreciate expert suggestions for the best strategy about updating solutions.

      For a number of reasons, my solution is made of:

      - 1 MAIN file with Tables for a total of some 700.000 records (number increases daily)

      - 2 Accessory files of 1 Table each

       

      Since I perform updating of the solution using scripts in sequential order, what would be the best practice for updating the MAIN file solution ?

      A- rename the older file ?

      B- keep the old file with the same inside a folder within the new solution file ?

      C - use a specific strategy ?

       

      Or in general, is there a guideline (that I didn’t find) for avoiding errors and producing the fastest reliable result ?

       

      Thanks for all the suggestions,

      Victor

        • 1. Re: Suggestions for Solution Updates
          Johan Hedman

          First off I would recommend you to have all tables in the same file.

           

          Why do you need to update your records? Is it updating both tables?

           

          I try to do as much updating as possible inside my current file. I work in separation model that you can learn more about here.

          WEB002 - Prepare Your Custom App for FileMaker WebDirect - Johan Hedman

           

          For any kind of updating function often use Loop to go through the records I have.

          • 2. Re: Suggestions for Solution Updates
            Mike_Mitchell

            I tend to take the production system offline to do migrations. Number one, it's faster than trying to do it on the server. Number two, it prevents data drift that results from users interacting with the database while I'm in the process of the migration.

             

            But for the process itself, I tend to script it ahead of time (use offline copies from backup), using sequential Import Records script steps (which are considerably faster than loops, at the price of less flexibility). Once the data are migrated and I've verified the record counts match between the old copies and new, I replace the old database on the server with the new one, keeping the same name.

             

            HTH

            1 of 1 people found this helpful
            • 3. Re: Suggestions for Solution Updates
              Wicktor

              Johan Hedman

              Thank you for your replay.

              I considered the separation model...Do you really recommend  it ?...one of these days I will have the "courage" of moving in that direction.

              If I understand correctly, you do not re-import all the records but only the newly added records through the loop.

              • 4. Re: Suggestions for Solution Updates
                Wicktor

                Mike_Mitchell

                Thank you for your replay.

                It looks like until now I was doing your same way:

                I use a backup file offline, I rename the old file like "FILE_OLD" and a script for each Table like:

                Go to Layout

                Import Records [No dialog; "FILE_OLD"; Add]

                 

                Ahhh so time consuming for large databases it takes overnight...MY question was because I am always curious if there are shortcuts that I was not considering. Maybe the separation model would make me save some time.

                • 5. Re: Suggestions for Solution Updates
                  Johan Hedman

                  I do recommend separation model for almost all my customers.

                   

                  For updating records, it is far better to just update records that needs to be updated. I most often use Perform Script on Server to do the Loop for me or have a Scheduled Script on FMS.

                  1 of 1 people found this helpful
                  • 6. Re: Suggestions for Solution Updates
                    taylorsharpe

                    The Separation Model is where you have a file with the UI only and a separate file with the data only.  But you don't put a table in each file like was stated above.  If nothing else but for simplicity in security and possibly some performance, I would put all of the data in one solution.  You might separate out the UI for Separation Model, I would not recommend that as a first approach. 

                     

                    There are a lot of good ways to do migrations that only look for records that have been added or modified and importing them only as well as determining any that need deleted.  That can be much faster than a full import.  Or you could get one of the Syncing tools out there like Mirror Sync from 360Works.  That would probably be the fastest and keep things very current on both files. 

                    1 of 1 people found this helpful
                    • 7. Re: Suggestions for Solution Updates
                      philmodjunk

                      The main advantage to using a separation model, when it comes to deploying new versions of your solution, is that the UI file can be simply swapped out for the new copy with no data importing required. Only when you make changes to the underlying schema in your data file, do you need to do any importing.

                       

                      On another note: if you use Get ( UUID ) to generate your primary keys, the import process for any data imports that you do have to do no longer require you to also update "next serial value" settings on auto-entered serial numbers.

                       

                      And there's another approach, that we use for ongoing design changes to a system in regular, heavy use:

                       

                      We work with a separate copy of the file to produce and test a new design and then carefully reproduce the design change in the live copy. Manage | Database | Changes are made while we shut down the system briefly once a week. Other changes such as updating a layout or a script, we do directly via a client session open with full access. This has to be done with care as the change can catch a user by surprise, but minimizes down time as well. All changes have to be carefully documented and I typically deploy changes in ways that allow me to find and "revert" them quickly should I miss some critical detail and discover after the fact that my update has messed something up. For example, I'll duplicate a layout before changing it and give the duplicate an "expiration date" a month in the future so that we know when it's OK to delete it. For a script, I'll preserve the original code in disabled state next to the new code with the whole thing encapsulated in dated comments that tell me what was changed, when and why. Such code is then free to be cleaned up by removing the disabled code a month or later when we next visit that same script to reduce the "clutter". (We have backups of everything, but the disabled code makes for a faster "restore".)

                      2 of 2 people found this helpful
                      • 8. Re: Suggestions for Solution Updates
                        Mike_Mitchell

                        Yes, it would, at least some of the time. If you have to change field definitions, you still have to do the migration, but if not, you can just switch out the UI file(s).

                         

                        Consider using a separate file for old data that don't change much (like an archive). This will speed up the migration, since the old table isn't likely to change.

                        • 9. Re: Suggestions for Solution Updates
                          Wicktor

                          Many thanks to all of you.

                          I am very glad of being part of this Community, always very helpful and very kind, with many skilled people always ready to help.

                          This Community is a nice place to be.