5 Replies Latest reply on Mar 23, 2017 6:08 AM by philmodjunk

    Keeping Developed and Production DBs separate




      I have been searching on how to keep a live production FileMaker Database separate from the developing database.

      Is this possible?


      How is it possible to keep developing a DB on a developing FM server, and then migrate the changes to the Production FM Server without losing any records that have been added?


      I have been reading on how to do this manually, which requires multiple steps and preparations to get this done.


      Thank you all for your help.


      Appreciate it.

        • 1. Re: Keeping Developed and Production DBs separate

          with data separation, changes can be made to the user interface file and then, when ready, you simply replace the previous interface file with the new.


          For changes to the data file, you have two choices:

          Close the file on the server so that no changes can be made during the update, then import all the records from the old into the new, updating any auto-entered serial numbers while doing so. This is a process can be scripted and tested/debugged ahead of time.


          While the file is closed on the server, replicate the changes in the data file. With FileMaker advanced, you can both copy and paste as well as import to move new field definitions or new tables into the data file. If you have a lot of data in a lot of tables, replicating the change may be faster than importing.


          Taking an existing file and splitting it into a UI and data copy is relatively simple, but can take some time if you have a lot of boxes in your relationship graph. You basically save a copy of your file and then turn one copy into the UI file by setting up an external data source table link for each table occurrence box to the correct table in the other copy, which then becomes your data file.

          1 of 1 people found this helpful
          • 2. Re: Keeping Developed and Production DBs separate

            I like the idea of splitting the UI and Data. It's just we will be using MirrorSync so that incurs more cost.


            Also regarding the import, Is there a way to mass import records across all tables?


            Thanks Phil appreciate it.

            • 3. Re: Keeping Developed and Production DBs separate

              Import records can only import records from one source table into one target table at a time and you have to explicitly name the tables.


              But a script can do this for each pair of tables in turn--it's one of the reasons that you want to script that process.

              • 4. Re: Keeping Developed and Production DBs separate

                I have some questions regarding this splitting up:

                1. do you have to maintain identical Relationship Graphs in both UX and Data DBs? Or do you purely have some disconnected tables in the Data DB, and all relationships and TOC in the UX DB?

                2. I did this setup earlier, but got really in a network fight (fixed versus var IP adres for server) when delivering this to multiple users. Can you set this up using variable IP addresses for the machine that hosts the Filemaker?

                3. If you develop a new version, is deploy then simply replacing the UX file with the newer version?

                4. Does this also work on FMServer15?


                Are there other specific problems ahead on this route?


                Thanks a lot already!

                • 5. Re: Keeping Developed and Production DBs separate

                  1. No and probably No. If a field definition refers to a related table, (calculation field, auto-enter option...), you need that relationship in the data file.

                  2. The external data source references should be relative path references that use the file name and that do not use Ip addresses. The UI file is usually hosted from the same folder as the data file so IPs do not need to be listed.

                  3. Yes

                  4. Yes


                  Specific Problems:

                  a) Security has to be set up and managed in both files. A UI script set to run with full access privileges no longer has full access to data in the data file.


                  b) Truncate can only act on local tables