2 Replies Latest reply on Aug 16, 2012 8:33 AM by philmodjunk

    Workflow for Updating a server database



      Workflow for Updating a server database


      Running my database on a server using the Filemaker sharing.  Once I go live at the end of this month, I'm sure there will be little bugs or enhancements that I'd like to make.  Is there a good workflow for doing this development locally instead of on the server database and then when ready, being able to replace/import or add the changes?

        • 1. Re: Workflow for Updating a server database

          Absolutely. Never work on the 'live', currently-being-shared version.  Make the last thing you do before going 'live' to write a script to import all the records from the current version to your new version.  Make sure it finds all the records in each table, goes through each table in turn and imports the data, don't use auto-updates, match field names (and then never change an 'old' field name in your new version - at least not for anything that isn't global or a calculation field).

          Then develop locally, and when you release the next version, run the import script.

          • 2. Re: Workflow for Updating a server database

            You might also consider designing your database to consist of two files, an interface file consisting of all layouts, scripts, value lists, etc. and a data file that only contains the tables and a few "backbone" relationships. With that structure, updates to the interface file can be deployed simply by replacing the old interface file with the new. Imports need only be performed when a change must be made to the design of the data file.

            Convert to Seperation Model