5 Replies Latest reply on Jun 22, 2012 6:45 AM by bright_guy

    Best Practice for Updating Files (Version Control?)


      Can anyone recommend best practices for updating database files? I am developing a solution for a customer -- let's call him Rex -- and periodically email him new versions.


      1. How do I import existing records into the new versions? Can I script this, so Rex can do it himself, on his end?

      2. How do I let Rex keep his old password?



      The solution contains two FMP files: an interface and a data file (separtation model). Updates currently require Rex to change his password for BOTH files, which means he has to enter a new password four times. No joy.


      For the next version, I'm planning for Rex to first e-mail me his latest, so I can import existing records into mine, then email it back. This can't be the best approach???


      Thanks in advance. Any help is greatly appreciated.


        • 1. Re: Best Practice for Updating Files (Version Control?)



          You can certainly script this, you need to make sure you're importing all of the tables, and also setting any serial fields along the way.  Also be aware there are some things you can't script ( accounts, custom value lists ).


          I built myself a tool to build these imports for me : http://www.goya.com.au/refreshfm  just because we were doing this same thing over and over.


          But if you decide to build it yourself, let me know of any questions, as I've probably come across them already :)




          1 of 1 people found this helpful
          • 2. Re: Best Practice for Updating Files (Version Control?)

            As nickorr said, you can't script export / import of accounts and custom value lists so my suggestion, for them, is to use tables in the data file for managing both users and values lists. It may seem redundant compared to the FM functions but I think this is the best approach for who's developing programs for clients and need to deploy updates.


            I use the separation model too and this is what I made for data.


            I've got two tables containing only global fields. These fields aren't editable by the user (only by the developer).

            • Interface file will have program_globals table containing:
              • sw_version field (e.g. 1.3)
              • db_expected_version (e.g. 1.2)
            • Data file will have database_globals table containing:
              • db_version (e.g. 1.2)


            In the case above, you will send to the client only the interface file  (the 1.3) as database hasn't been upgraded.

            The client will just have to replace the file and do nothing else.


            A script at the program startup will check db version and guide the user to the eventual data upgrade.


            Let's do the case where the data file has changed (db_version is now 1.3).


            The client will have to do these steps:

            • replace the interface file (that will find that db_expected_version <> db_version and ask the users to upgrade the database)
            • run the "export data" function (see below)
            • replace the data file with the new and empty 1.3 version
            • run the "import data" function (see below)



            Export data script

            Foreach table you will need these script steps:

            • Go to layout ["table1"]
            • Show all records
            • Export Records [No dialog; "export_table1.fmp12"; Unicode (UTF-16)]  on which you specify the export order. Please note that you'll have to script the export order using the new table schema (despite what are the fileds of the previous version). This command will be run, at runtime, exporting all the fields found on the database (for instance v.1.2) just ignoring, without any error, the fields not found (the ones newly available on 1.3).


            Import data script

            Foreach table you will need these script steps:

            • freeze window
            • go to layout ["table1"]
            • Import records [No dialog; "export_table1.fmp12"; Update existing; Mac Roman]  on which you specify the import order. As for the export command, when you import from a file whose fields are less than what expected (e.g. 9 fields of v.1.2 instead of 10 fields of 1.3) you won't have any error and the script will just work
            • Set Variable [$ID; ExecuteSql("SELECT MAX(Id) FROM table1";"";"") + 1]
            • Set Next Serial Value [Table1::Id; $ID]



            Hope this will be useful.



            • 3. Re: Best Practice for Updating Files (Version Control?)
              Stephen Huston

              In addition to the ideas given above, two other ideas might save some bother:

              1. Set the interface file to open with a default user-level account so that your client needs only only to login for the data file. If anyone else tries to use the solution, they would still be challenged for the data file account info. This will avoid haivng to change passwords in both files to match.
              2. Next time you provide an updated data file, stick in some unused date, number, and text fields for future use in the main table(s). These can then be pulled up and used via the interface file when needed so that you can make some changes in the interface file without needing to mess with the data file for the occasional new data field. Just reference the waiting extra fields in the data file in your revised interface file.

              Hope that helps a little.

              • 4. Re: Best Practice for Updating Files (Version Control?)

                This is awesome. Thank you Powell. Can't wait to try it out.



                • 5. Re: Best Practice for Updating Files (Version Control?)

                  And thank you Stephen. You guys are awesome. Will try your suggestions soon. Must cut grass first.


                  Thanks again,