2 Replies Latest reply on Jan 5, 2015 2:11 PM by philmodjunk

    Working on live databases

    JasonRoesler

      Title

      Working on live databases

      Post

      Hello,

       

       

       

      Hoping this one has an easy answer, I'm responsible for building and maintaining our new filemaker database at work. I have created and will soon deploy a system for tracking contacts information (stage 1), after this I will create a module to manage repairs and orders etc (stage 2, 3, ... ). I plan to work on the new modules offline on my laptop (mostly off site with no internet connectivity) and deploy the updated filemaker DB when ready on site.

      My question is: once stage 1 is deployed and staff begin entering data in how to I merge the working DB and the new updated DB together once later stages are ready for deployment? Would I import all records from the working DB into the new DB or do I import the new Tables, layouts. value lists etc into the working file?

      Thanks,

      Jason

        • 1. Re: Working on live databases
          Mark_M

          >

          I would think that a very high priority would be maintaining the integrity of the existing database prior to incorporating changes.  To manage this well you might want to consider the following:

          1.  Maintain in unchanged copy of the stage 1 database, if something goes wrong then you can always revert back to this copy while troubleshooting and making corrections to the next stage.

          2.  Document a data export process (in other words how is data migrated from state 1 into state 2).

          3.  When you are ready, take the data from state 1 and then import it into a TEST copy of the state 2 database.

          4.  Perform what my group calls a "Conference Room Pilot" (CRP).  The purpose of the CRP is to bring actual users into a testing environment and have them run through their paces.  The purpose of this is to put users hands on with the changes and determine what the problems are, what did you not get right as a designer, what things can they accidently screw-up that you need to prevent.

          5.  After CRP go back to the drawing board and make any corrections/updates needed.

          6.  Repeat CRP after corrections.  (All this time stage 1 is up and running and still available for "production".)

          7.  Once stage 2 is ready to "go live", backup an unchanged copy of stage 1 as a backup that can be restored if there are problems.  Deploy stage 2 after importing all the "live" data from stage 1.

           

          >>>>

          • 2. Re: Working on live databases
            philmodjunk

            You might also consider using the Convert to Seperation Model approach. It splits your file into two parts, Interface and Data. This reduces the frequency with which you need to export data as you can replace interface files with new copies (or revert them to an older copy) without having to import any data from one file to another.