2 Replies Latest reply on Apr 11, 2015 11:40 AM by drduane

    Modifying Database on FileMaker Server

    drduane

      Title

      Modifying Database on FileMaker Server

      Your post

      I am a neubie FileMaker Admin/Developer for a small company with no other FileMaker expertise in the company. As we approach going live I have been trying to find the best practice for modifying/updating a database file that is being hosted on a FileMaker 13 Server. My development platform is FileMaker 13 Pro Advanced - currently not located on the server.

      Obviously I can download the database file and make small changes and put back on the server during off hours when no one is using the database. What I am not clear on is a large change that might take days (or weeks) and the database is in use with new data being loaded while I'm making changes. What is the best practice to make significant changes and keep the data in sync? What is the best practice for making table changes where new fields are added and data needs to be migrated to the new table structure?

      Any advise would be much appreciated.

        • 1. Re: Modifying Database on FileMaker Server
          philmodjunk

          Obviously I can download the database file and make small changes and put back on the server during off hours when no one is using the database.

          This is the safest and best way to make both large and small changes. Of course this creates a number of issues, but there are problems and risks inherent in making changes to a live, hosted database:

          1) When you commit database changes back to the server, if you get a "glitch" at just the wrong instant of time, you can get a damaged database file. This risk is highest for the type of changes that you would use Manage | Database to do such as modifying a table's design, relationships or changing a calculation specififed for a field.

          2) When changes to a table are being committed (by clicking OK in Manage | Database), the table is locked and no changes by other users are permitted until the update is complete.If another user is performing a script, this script could fail to update records and the results could be very ugly. Just opening the specify calculation dialog to examine an auto-enter calculation locks the table against changes until you close the dialog.

          3) Any design change, even a layout change might catch users "between stools" so such changes should be made with caution and taking care to stay in communication with users as to ongoing changes.

          Changes to layouts, scripts, value lists--interface level changes, have a much lower level of damaged file risk and most developers supporting a hosted file routinely make them while keeping in mind the issues previously listed.

          One option often used is to make major design changes to a copy of the database and when you are ready to deploy, you save a clone of the database and then, during off hours, take down the database and use a script with multiple Import Records steps to import all the data from your older version into the new.

          Also, a Convert to Seperation Model approach can be used to produce an interface file that can be updated without the need to import any data in the interface file. This can reduce the number of data imports needed to implement updates.

          • 2. Re: Modifying Database on FileMaker Server
            drduane

            Thanks for your response. I was afraid that was going to be the answer. However, I think I will definitely look at the 'Data Separation Model'. Separating the the frontend from the backend would at least make it much easier to modify the interface.