2 Replies Latest reply on Jun 8, 2014 5:29 AM by RickRobbins

    Updating a live file

    RickRobbins

      Title

      Updating a live file

      Your post

           I have just uploaded my database file to filemaker server 13 and this is my first filemaker application that I have developed.

           I am now trying to understand how to make changes (updates, new functionality, etc.) to my "live" file.  Is there a way to work on a copy of the database file to continue development and then just upload the scripts and layouts?  Are there "best practices" for continuing development of a solution?  

           It seems as if I have to work on the "live" database or bring it down (kick all the users off) and then do my development.  This is not very efficient if I need to make major changes that take weeks to develop.  I am sure I am missing something here.

           Thanks in advance for any help!

        • 1. Re: Updating a live file
          philmodjunk

               Let's address the most seductive option for a database file currently hosted over the network:

               Can you connect to the database via a full access password and make design changes to the file?

               Yes.

               Should you?

               That would be (IMO) a qualified No.

               The "best practice" answer you will typically get from TS personnel that work for FileMaker is that you shouldn't do it and they have very good reasons for recommending that. The reason is that if you make a design change to the database and a "network glitch" happens just at the moment your change is saved (committed) it can damage (corrupt) your database file.

               To that, I will add that many design changes will "lock" all other users out while the change is being saved and in one case you can lock them out if you just open Manage | Database and open Specify Calculation for an auto-entered calculation.

               Even without those issues a sudden design change can confuse the users when a layout suddenly looks different or a script does something new.

               It's a bit like changing the spark plugs while others try to drive the car down the freeway. wink

               But I "qualify" that no, because I actually do make some design changes right in the "live" database.

               a) I have a full back up system in place

               b) I only make certain "low impact" design changes, such as creating or modifying a script or a layout. I don't touch anything in Manage | database.

               c) Any design changes with directly affect users are at least "rehearsed" on a copy and/or tested on a duplicate of the current layout before making the change "live".

               So most significant changes would be made to a copy of the file which you'd then upload back to the server. But this creates problems. The data in your new copy will not match the current hosted copy as changes were made while you developed the new version. At the very least, this requires that you close the current copy to "freeze" it from data changes, import all that data into a clone of your development copy and then you upload the new copy to your server. This can be tedious and require careful attention to details--such as updating auto-entered serial number fields in the new copy to avoid creating records with duplicate serial number values. But this can be scripted to reduce operator error and make it go more quickly.

               And a key way to reduce the number of times that you need to import data when you are deploying a new version, use the Convert to Seperation Model technique with your files split into an Interface File and a Data File. Design changes made to the interface file will not require importing data and so you can simply replace the old file with the new to deploy a new version. Only changes to the data file will require updating.

                

          • 2. Re: Updating a live file
            RickRobbins

                 Thanks Phil!! This was exactly what I was looking for.  One other question.  In terms of performance accessing the FMP database over the internet.  Is it better to have the "interface" file local for each user or also stored on the server.  I am not sure if local for each user could cause unexpected errors.

                  

                 Thanks again!!