6 Replies Latest reply on May 2, 2014 2:13 AM by Boutsy

    Update a solution by a "universal script" or plugin.

    Boutsy

      Hello,

       

      We are all developing solutions. We make them available and we continue developing on that solution, while it is used on the server or separately.

      If we continue the development separately, we will have to import the data from the previous version of that solution, table by table and lookup the next values of the serial numbers and paste them in the updated solution.

      This can all be done by a script, but that script will have to be written specifically for that solution and if you created new tables or values with a serial numbers in the new solution, you will have to take care of that in the that script.

      My Question :

      Is there u plugin or "universal script" out there that can take care of all that?

      This would be great.

      It would even be greater if you could send an update to a client and that he only had to push "update" and everything will be taken care of automatically

       

      Thank you in advance,

       

      Marc

        • 2. Re: Update a solution by a "universal script" or plugin.
          DrewTenenholz

          Marc --

           

          MirrorSync -- <http://www.360works.com/filemaker-sync/>

           

          The folks at 360Works needed to solve the same problem you describe.  This was their solution.  MirrorSync can do more than provide a method for you to make design changes in an 'offline' copy of a system and then sync up the data records, but it certainly does just that.

           

          -- Drew Tenenholz

          • 3. Re: Update a solution by a "universal script" or plugin.
            BobGossom

            Marc,

             

            This can be done with third party products, as others mention, but you can also program it yourself.

             

            While the process can get complicated, at it's essence it's simply a matter of importing all of the data from the old solution to the new one, and after the imports updating the next serial number, if required. If the files have the same name, they can't be in the same folder, or you can increment the name for each build. You can specify the import path with a variable, so all of this can be programmed. We've done both, sometimes incrementing the build, sometimes requiring that the "old" file be in a specified folder ("[solution name' OLD"] if we aren't changing the name.

             

            One thing you have to manage carefully is the import field matching. If it's matching names, you can't change field names. If it's creation order, you can't delete fields. My preference is matching names, but I know developers who use the creation order.

             

            As you develop you have to think about how new features need to be implemented. Sometimes you'll have to add maintenance routines to the import process to "massage" the data for a new feature.

             

            There are a LOT of potential twists and turns to doing this, whether you use third party tools or not, but the benefits of automating the process are huge. We roll this into almost every solution we write.

             

            Bob Gossom

            • 4. Re: Update a solution by a "universal script" or plugin.
              nickorr

              BobGossom wrote:

               

              One thing you have to manage carefully is the import field matching. If it's matching names, you can't change field names. If it's creation order, you can't delete fields. My preference is matching names, but I know developers who use the creation order.

               

              Which is why we wrote a "Matching IDs" feature into RefreshFM.  So you can delete AND rename fields in the same table and it will still match them up.

               

              Cheers,

              Nick

              • 5. Re: Update a solution by a "universal script" or plugin.
                PeterWindle

                Just to add even more confusion to the mix...

                 

                I have developed a solution that uses a data separation model to "upgrade" solutions. 

                This only works if there is no change to the table/field structures. "upgrading" the solution is as simple as saving a copy of the existing GUI file with a different name, then placing the new file in the same place as the old file (with orginal name).

                 

                I have implemented 3 files, the GUI file (which gets replaced during an "upgrade"), the table/fields file (aka DATA file) and the third file which controls the actions (which I call the Utility file) that should occur in the other two files (calls scripts in the other two files)

                 

                There are dangers, caveats and just annoyances when doing this, so plan it carefully!

                 

                eg: I found a weird situation once where a calculation field was not refreshing on the GUI file layout (even with refresh scripts) - it wasn't until I called a refresh script in the DATA file, then refreshed in the GUI file that it worked. Grrrr...

                • 6. Re: Update a solution by a "universal script" or plugin.
                  Boutsy

                  Hello jml,

                  It seems that refreshfm from goya doesn't work for FMP13. I've sent them a question concerning this a few days ago, but I didn't get a response.

                  Thank you,

                  Marc