5 Replies Latest reply on Oct 8, 2009 6:14 AM by Steve Wright

    Version control and data

    AaronNeville

      Title

      Version control and data

      Post

      I'd like to establish a development process whereas I can work on a "development version" of my files and port the "changes" over to the "production version" leaving data alone (for the most part) and only adding tables, layouts, scripts, etc.

       

      I understand that there is a third party VC program, but I'd can't get past the fact that there is nothing that I can do without spending more money. What are you doing or does everyone work on the live versions of their files. Thanks.

       

      FMP10; Mac; Windows; Intermediate Dev

        • 1. Re: Version control and data
          philmodjunk
            

          Mostly, modify development copy and then import the data.

           

          You can split your database into two files.

           

          File 1, the front end, has all layouts and scripts. File 2, the back end, has only the tables and any relationships needed to support calculation fields and auto-enter requirements. Since most updates will only involve changes to to File 1, you can then update the file by swapping old copies  of file 1 with the new and you won't have to import data.

          • 2. Re: Version control and data
            AaronNeville
              

            In hindsight, that sounds like a good option, but at this point, I'm worried about breaking too much or having to start over on some aspects. Guess I might just have to try it and see how it goes. Thanks. 

            • 3. Re: Version control and data
              philmodjunk
                

              It's actually pretty easy to split a database into front and back ends.

               

              Save a copy of your file, then open the file you want to use as your back end and use Manage | Database | relationships to redirect each table occurrence from the current file to your 2nd copy. Then delete the tables from the front end file and the scripts and layouts from the back end file. As always, keep back up copies so you can revert back if things go awry on you.

              • 4. Re: Version control and data
                AaronNeville
                   I'll go ahead and try it out. I had just thought that there would be some problems with linking to a new file, but I suppose if the table instances are named the same as they were previously, then nothing should break. Thanks.
                • 5. Re: Version control and data
                  Steve Wright
                    

                  Just my personal opinion on data separation in filemaker....

                   

                  I almost went this route myself, however am finding most updates involve adding new fields etc, so for the effort required to convert a single file into front end / back end seems pointless

                   

                  There are also some issues with how data is evaluated which you may come across, altough there are workarounds to most of the issues,
                  Ive now decided its more practical to work on a single file basis, then release a copy of that blank file with a scripted data import to bring data in from the clients original file.

                   

                  I suppose it also depends on the amount of data to be held in the database, how frequent changes are to be made and also what types of changes you are planning to make.

                  If you are likely to be adding lots of new database fields, calculations (in the data table) etc, then I dont see any benefit of separating the UI from the data