1 Reply Latest reply on Jan 12, 2013 10:55 AM by philmodjunk

    Development vs. Production

    AndrewGehring

      Title

      Development vs. Production

      Your post

           What are the rocommended procedures for managing a app/db in two (or more) 'environments'.

           We would like to create a 'development' environment (clone?), but how do we "update" a production environment without losing/corrupting data?

            

           Thanks!

        • 1. Re: Development vs. Production
          philmodjunk

               First option to carefully consider is whether to use a Convert to Seperation Model. With this approach, you have an interface file with all the layouts, scripts etc, but no data. You can deploy updated copies of this file at any time and not need to import any data into it. This can greatly reduce the number of times that you have to import data.

               Second option is to set up scripts for pulling all of your data from all of your tables in the previous version of your file into the new version. When it comes time to deploy a new version, you take the file down off of the server (do not leave a copy up that permits data modification during this process), run the script, then put the new file up on the server. Such a script can both transfer data and update serial number settings all in one operation. Sometimes, if your data model supports this, you can do the import in two stages:

               Stage 1, import all data that cannot be changed by normal access level users. THis can take all night if necessary.

               Stage 2, complete the import process, importing only newly added records and records from "volatile" tables where the data is subject to frequent changes.

               Since users only have to be locked out of the database during stage 2, this can reduce the "down time" when dealing with massive numbers of records to import.

               Third Option: With some small changes such as adjusting a layout's design, changing a few lines of a script, etc, you can make the change on the "live" database. Some types of changes, such as those requiring opening up Manage | Database, should never be done if there is any chance that someone else is using the database as you can "lock" people out of entire tables while working with that part of the system. There are risks entailed in this approach so proceed with extreme caution and lots of backups if you choose to do this.

               When making such changes, I often "rehearse" the change and test it out on a back up copy of the file, then copy and paste it into the live database, preferrably in early/late hours when no-one is accessing the database.