3 Replies Latest reply on Aug 1, 2015 2:32 AM by nodisorder

    Best Practice for Updating a FM Solution


      I have looked over a lot of materials on the pro vs. con of separation model and have concluded that a separation creates more issues for my solution that it solves. That being said, I have been struggling to get my mind around maintaining multiple sites with updates going forward. I would appreciate any insight in methods the more experienced members use to update their solution(s):


      • Scripts
      • Layout modifications
      • Database Scheme changes


      RIght now, I have been gravitating towards installing a new version of the solution (empty, without any records) on the server and scripting a data import for each table required from the old version to the new shell solution. Because I am using UUID for PK's this avoids some PK problems and works, but it is slow (there are millions of records in several tables at some locations) and I worry about data corruption. Thanks.

        • 1. Re: Best Practice for Updating a FM Solution

          I routinely use scripted routines for data migration, but have avoided having the database on the server for two reasons. First, the performance isn't so good, since you're dealing with network issues that may be significant (depending on the environment). And second, you have to do something to keep the users' fingers out of the solution while you're performing the migration. I went to a session at DevCon this year about data migration, and the presenter did state that he does his migrations on the server, but uses a "redirect" to bounce users over to a "Maintenance In Progress" file.


          It's probably just me, but that sounds like a lot of extra work to set up when you can avoid the whole issue - and the performance hit - by just doing it locally. When the migration's finished, you just upload the new version to the server to replace the old one. Others may have a different take.





          • 2. Re: Best Practice for Updating a FM Solution

            I give you the thumbs up. Thats exactly how I do it for the last 15 years.


            It is fine that someone can implement a "server work in progress" diversion file to show up and it might be necessary for solutions in large organizations working 24/7 but I play it save and to to actual an upload which is done locally in 10 to 15 minutes.

            I do the following:

            1. upgrade the core and test in FMPA locally and then in isolated test environment
            2. clean the shell
            3. reset all ID counters
            4. clean security access and other settings
            5. prepare a list of user preferences and security setting for access
            6. export data from existing dB
            7. run test import scrips into new application (and test for bugs) and checking conversion log !
            8. flush dB again
            9. do another import and implement as much security settings as possible at this stage
            10. save file(s) to thumb drive
            11. stop FM server and all related process
            12. send msg from server (or sometimes not when doing at night time)
            13. move old dB to (old folder)
            14. upload new dB to server
            15. server restart
            16. start console
            17. adjust settings in console as required
            18. test login etc.


            If possible do it at night time and with full serer access, either physical or remote access.

            It works just fine for 15 odd years, can't be so wrong.  ;-)

            • 3. Re: Best Practice for Updating a FM Solution

              Take a look to RefreshFM | Goya Pty Ltd


              We are not using it but we have colleagues that are using it with success and dropped any kind of manual scripting for importing procedures.