1 Reply Latest reply on Aug 19, 2014 9:18 AM by philmodjunk

    FileMaker Best Practice--splitting databases

    mmorin

      Title

      FileMaker Best Practice--splitting databases

      Post

           Hello!  I am relatively new to FileMaker having developed only a couple databases in it versus numerous databases in Microsoft Access.  A practice I've always employed in Access was splitting the database keeping forms, reports and queries in one database that then links back to the Data tables in a separate Database. 

           I have accomplished the same in FileMaker but it is rather clunky. Given they don't make it easy I wonder if I should even be doing it at all.  What I'm stuck on is how do I update a deployed system while not impacting live.  I recognize I can copy the entire database to a different location then make the modifications and just import elements I changed back into live.  But how do I manage that when there could be multiple changes and missing one change to a layout could be quite easy especially when you get into debugging and such.  Or if there is a lot of data, I don't really want to copy it all.

           I guess my question is how do others handle updates to complex programs.  It sure would be easier to have it all in one database, but I worry.

           I am using FileMaker Server 13 with clients accessing via FileMaker Go and FileMaker Pro. 

           I am developing on FileMaker Pro Advanced 13

           I appreciate any insight you can give me.

            

            

            

            

            

            

            

        • 1. Re: FileMaker Best Practice--splitting databases
          philmodjunk

               While not as simple as in Access, I haven't found splitting a FileMaker Database all that difficult to do: Convert to Seperation Model

               A data separation model is a quite reasonable option. But whether you use that method or not, The time will come when you need to move data from one file to another. (Even data files need updating at times) The import records process can be scripted so that the user need only click a button or can click a button and then select the original file in an open file dialog. Then the script pulls in all the data and updates the next serial value on any fields with auto-entered serial numbers.