3 Replies Latest reply on Apr 7, 2011 11:46 AM by philmodjunk

    (Relative) Newbie question on release management

    StefanSievert

      Title

      (Relative) Newbie question on release management

      Post

      Hi,

      I have been learning FM for a while now to be able to help enhancing a solution my wife uses at her business. I am a very experienced IT person (since 1983, scary...Embarassed) and I am struggling with identifying a reliable way of implementing and testing changes to the solution and then roll them into the production version my wife uses daily; given the FM architecture.

      Is there a best practice that should be followed that would allow not having to work in the live version? I am aware of a couple of suggestions relating to keeping layouts in separate files from the data and that makes things a bit easier. However, I still need to apply schema changes to the database once all testing has been succesfully completed and I don't see how to do that with minimal risk and other than manually.

      I would appreciate the comments from more FM experienced folks out there. Pointers to documentation are perfectly fine, if there is a good source that I could go to and read up on.

      Appreciate any and all input.

      Thanks for your time!

      Stefan

      PS: Yes, there will be backups before any change to be able to recover to a defined state, so that's not the answer I am looking for... ;-)

        • 1. Re: (Relative) Newbie question on release management
          philmodjunk

          Data separation is the first thing and you are already doing that.

          The alternative to making changes to the live database (and that's not at all a good idea when they are schema changes), is to modify a copy of the data file and then import the records from your live file into the new copy, then swap the files. This import process can be scripted so that all records from all tables are imported and serial number fields get their "next serial value" settings updated so that it's all automatic.

          • 2. Re: (Relative) Newbie question on release management
            StefanSievert

            Thanks 'PhilModJunk',

            I totally agree with the 'bad idea' comment and my initial feeling about the data import is even more scary. I will nonetheless try to find some examples of such scripted import/swap approaches.

            I inherited the solution and it was VERY obviously built by someone with absolutely no design/programming background, so I don't get a very warm and fuzzy feeling thinking about what may happen. There are weird things happening already and I don't have an easy way to validate consistency and success (the same thing, really) after doing the data import.

            I guess another good idea is to do more and smaller changes to limit the amount of things that COULD go wrong.

            Thanks for taking the time to respond, I appreciate it!

            • 3. Re: (Relative) Newbie question on release management
              philmodjunk

              For others reading this thread, if you make design changes to the table design on a "live" hosted database and you are disconnected by a network glitch in mid change, you can corrupt the file according to posts from TS personnel that I have seen here in the forum. From my own experience, I have also discovered that if you click OK to dismiss Manage | Database and apply the changes made, the update tables are briefly locked against any changes to their data by other users. If another user is running a script at the same instance that I do this, we don't always get an error message back, but now some of the edits that should have been performed by the script did not take place. You don't get any warning, so the only way you know that this happened is when reports or scripts don't display the data they should or fail to perform as expected.

              I do make certain, small design changes to some of our larger files while they are hosted, but I also have taken the following safety measures: I make the change after close of business when I am sure that no one is editing a record or running a script that modifies data. I do this only on hosted files that makes frequent automatic back ups of the file so I can easily replace the file with a backup if I should get disconnected during the updated.