8 Replies Latest reply on Dec 5, 2011 6:45 PM by pbqc

    Updating to a new version


      Hi, I am a new FM developper. I will be releasing version 1 of a db system to a client in the next week. But, there will be a version 2 of that system, to be release in a couple of weeks. My question is : How to deliver version 2 to my client, without wiping data collected in version 1 ?


      Thanks in advance for your help,



        • 1. Re: Updating to a new version

          Hi Pierre, and welcome to the list,


          You will need to perform an import of the data for each of the tables in your files. Generally you would clone your v2 build so those files have no data, then open that build and perform the import using the v1 files as the source. Developers normally script this so we don't have to do it manually each time. There are also tools that can help with this process since setting serial number values for your primary key fields is something that also must be done during this process. Look for RefreshFM http://www.goya.com.au/refreshfm

          • 2. Re: Updating to a new version

            Wow !  That was fast, thank you so much !

            • 3. Re: Updating to a new version

              Hi Pierre,


              you can try Shearns suggested product, but it's not very complicated technique. Mainly you have to copy all data from Old file to new one and you can do that using FM scripts. We have put this technique to our free sample database which you can download from: http://www.yzysoft.com/printouts/yzy_soft___Sample_Database.html


              Check the scripts in the Manage Scripts > Folder: 02 File and I think you will find out quickly how everything works. If you will have more questions do not hesitate to ask.


              Good luck,


              1 of 1 people found this helpful
              • 4. Re: Updating to a new version

                Great !


                Thanks a lot



                • 5. Re: Updating to a new version

                  Pierre -


                  The other folks have given you the basics. You may also want to look at what's called the "separation model". There's a section in it in the white paper on Migration Foundations and Metholdogies, available here:




                  Starts on page 112.


                  Basically, it means you split your solution into one or more interface files and one or more data files. If you make changes only to layouts, scripts, etc., then you don't have to worry about migrating data. It's not perfect - if your new release involves schema changes, then you still have to migrate the data - but it can often help.





                  • 6. Re: Updating to a new version



                    As usual very good replys, but forgive me for saying that this time the answer marked as correct is indeed so, but absolutely not compleete. And without step 2 and 3 + probably 4 in my list you may be in trouble when importing


                    Updating from a running version does at least need a few extra steps, here I will include the one mentioned in the previous answers:

                    1. Import the data from each table in each of the existing tables to the same tables in the new version.
                    2. Set the counters (serial numbers) for each table's keys and other counters to make sure that it is counting correctly ahead - if nout you may be creating duplicate snr's and be on your way to chaos.
                    3. Use a suitable method to make sure that you have the right accounts in the new version. Very often users in the production version will have got new serial numbers or new users was created*
                    4. Does the new version expect values in some fields that was not present in the previous version or has some fields previously optional been made mandatory etc. etc.


                    It is a good idea to start documenting for deployment of the next version already while developing. When you make a change that need some other thoughts or actions during dataimport or deployment, write it down.


                    * Accounts, this is a discussion that could very well end op in a religious infight. So let me just give you two options for handling of accounts and passwords in a solution that has to be updated every now and then:


                    MethodHow to
                    With stored passwords in a FileMaker TableCreate a user table with usernames, other relevant information on the users and some way of storing the password. You can choose to store the password in an ordinary field on the record, in a field in a 1-1 related table with special access or you can consider storing it in a field with cryptation (plugin or other solution). Then you can use a script to make sure that the accounts and pw's are OK in the new version of the solution.
                    Without stored passwordsCreate a user table with usernames, other relevant information but without the passwords. When deploying use your script to reset the passwords in the files to one that is emailed to the user and with the setting that the user must create a new password on next login.

                    In a solution with multiple files, and I do recomend that, I would really like to go for the solution with the pw's stored somewhere so that I am able to set the solution the right way. But thats another discussion.


                    Message was edited by: CarstenLevin

                    • 7. Re: Updating to a new version

                      Thank you Mike, great reading !



                      • 8. Re: Updating to a new version

                        Thank you very much.