6 Replies Latest reply on Mar 11, 2016 6:16 PM by bigtom

    Updating solutions for clients


      Hi there!


      I have several questions that have been on my mind. I would appreciate any help!


      I have created a solution for a client. They have only one computer and that's all they use. It's an inventory manager. They do not require Internet usage either as they just work off their PC.


      If later down the road they want updates to the layout or add more features, how would I go about that? Would I just update the file on my PC and copy it to their computer? What about the data they already have stored? I don't want to have to stall their work so I can process some updates. What I'm trying to say is that is there a way I can push an update from my computer to their computer without affecting their work flow via an Internet connection?


      Also does it work the same way to update a solution on a server?


      Lastly, my client purchased FMP14. If he decides to upgrade his PC, would he still be able to use the same FMP14 he purchased with the same key on the new PC?


      Once again, thanks for the help!

        • 1. Re: Updating solutions for clients

          There are several solutions.  One is to use data separation, where the solution data is in one file and the ui is in another.  What I have done is use scripts.  When I update their system, I rename their old file to filename-OLD.fmp12 and copy the updated file (NEW) to their system.  I then run the script that first deletes  ALL records in ALL tables of the NEW file, then exports ALL records from each of their tables to the same tables on the NEW file. If you have serial numbers for unique record ids, you must also copy the next serial number from each of their old tables into the new tables.  UUIDs make it easier.  Others may have different methods to solve this common problem.


          • 2. Re: Updating solutions for clients

            On a server I generally update the solution live taking care not to lock the database by keeping the database manager open, or do the change overnight.

            Otherwise if it's a large change I do the changes in a copy and then transfer the changes one by one.

            Otherwise if the same solution is on a number of different solutions then I do what is mentioned above, I program an update script that will copy all the data from the old solution to the new solution and then run that on each server.

            • 3. Re: Updating solutions for clients

              Mark B,


              Regarding your suggestion to use scripts to transfer data from OLD to New, any tips or suggestions?  Am looking to build a script for a pro bono charity organization to accomplish this and would appreciate any lessons learned in developing the scripts to accomplish the transfer of data.



              Mark S.

              • 4. Re: Updating solutions for clients

                Hi Mark,

                I did a lot of trial and error.  The first thing I did is to rename the file with the current data but old schema as {filename}_OLD.fmp12.  To avoid confusion, I'll call your modified file as NEW even though it has old records, and the file with the new records but old schema as OLD.  So even though the new file has your new modifications, it still contains old or missing data.  Make sure you have a good backup of your NEW file because you will need to use it over and over as you work through the script and fix bugs.  The OLD file isn't messed with except possibly adding some new scripts.  The way I got started is by asking myself how would I do this manually.  So your first step would be delete all records in the NEW file that has your new revisions.  Then you would work one table at a time and import the new data from the tables in the OLD file into the same tables in your NEW file, making sure you selected all records in the OLD tables before importing. If you use serial numbers, you must reset the next serial numbers in the NEW tables.  There are script steps that allow you go get this info.  I hope this helps you get started.


                • 5. Re: Updating solutions for clients

                  If you use fields with "serial values" then be sure to use the "setnextserialvalue" script step after importing a table so that you don't get duplicate serials.

                  • 6. Re: Updating solutions for clients

                    Moving to data separation is a good idea if you are mainly making UI changes. You can actually develop a UI file alongside your current single file. Once all the scripts and value lists are worked out in your test environment you can send the UI file to the client and it will work even though the data file still has UI elements on the layouts. Not optimum but will get your UI changes implemented without downtime or need for data imports and this may work best for the client. This is also quite nice if they are ever going to use FMGo as the UI can stay on the iPad for speed and the data on the PC using peer to peer hosting.


                    If it is not on a server some clients may have trouble understanding that there are two separate files, but you can stick the data file in a known folder and keep it out of reach of the client.


                    Since you are not on a server and if you make changes in the data side scripting the data import is the answer.