6 Replies Latest reply on Mar 25, 2009 3:01 PM by ralvy

    Upgrading a client's runtime solution

    ralvy

      Title

      Upgrading a client's runtime solution

      Post

      Still very new to FMPA. I created a runtime solution that employs data separation. I have finally come to the point where I need to alter the data file's structure (add a couple of fields to a particular table). So I can no longer just send my client the latest interface file and have them just overwrite the old one with the new one.

       

      I have questions about some things I read in the FMPA Help docs ...

       

      1. I'm told I need to Convert the old file before importing data from it into the new solution data file. Is this only if I'm moving the client from a file format that's older than FP7? The solution (both old and new) was made with FMPA 10. Can't I just import (using a script) without running a convert?

       

      2. I'm told I must use a different 3-character extension for the new solution. Why is this? Can't I just point my import script to the older file with the same name, as long as it's in a different folder? If I'm sending out an upgrade weekly to this client during the beta phase of this solution, I'm going to use up a lot of different extensions if I have to use a new one each time. Also, the Windows registry will get populated with all these useless (abandoned) extensions if I do this.

       

      From my very novice experience with FMPA, it seems like I should really be able to just do the following, assuming the two files my client has are interface.usr and data.usr:

       

      A. Using the same bind key I used to create the old interface.usr and data.usr, bind a new solution to the same .exe I did with the old solution, using the same extension I did before.

       

      B. Create a script that imports records from the old data.usr. This script will point to a subfolder of the new solution called "Old". Attach a button to interface.usr that runs this script.

       

      C. Send the new interface.usr and data.usr files to the client. Tell them to create a subfolder called "Old" and then copy their old data.usr file to that subfolder.

       

      D. Have the client overwrite their old files with the new interface.usr and data.usr files in their home folder.

       

      E. Have the client then run the old rumtime .exe file, which will see the new interface.usr file and load it. Then have them press the upgrade button I created, which imports records from Old/data.usr into data.usr found in the home folder.

       

      Again, none of those steps include running a Convert, and none of them involve using a new extension. Also none of them involve sending the client anything other than the two .usr files (no runtime .exe file, no dll's, etc.). Is this okay?

        • 1. Re: Upgrading a client's runtime solution
          obeechi
            

          Maybe you should join Technet.

           

          What would you be converting to if it's not an older version of FileMaker? Older versions extension different than fp7, which is three characters.  

          • 2. Re: Upgrading a client's runtime solution
            ralvy
              

            What would you be converting to if it's not an older version of FileMaker?

            Well, that's what I was wondering. The reason I asked about this is because the FMPA Help docs tell me I must offer the client a script that does, at a miminum, three things:

             

            1. Convert file.

            2. Import file.

            3. Close file.

             

            I was wondering if only needed to Convert the file if was created with an older version of FMP.

             

            The Help docs also insist on my using a different extension for the upgrade I provide my client. I didn't see a reason for this.

             

            Now that I read over the docs again, I'm wondering if they're simply talking about upgrading my client to a runtime created with a newer version of FMP, not just a newer version of my solution. The title of the Help doc is Importing data into upgraded runtime solutions (FileMaker Pro Advanced).

            • 3. Re: Upgrading a client's runtime solution
              TSGal

              ralvy:

               

              Thank you for your post.

               

              The conversion of files is solely for file formats prior to version 7.

               

              Some users find that an updated solution introduces a new problem that didn't occur with the previous version.  Therefore, I would use two extensions and switch back and forth.  That way, if a new problem is introduced, the users have a previous version to fall back on.  If not, you would have to go back and create the older working version.  Does that make sense?

               

              TSGal

              FileMaker, Inc. 

              • 4. Re: Upgrading a client's runtime solution
                ralvy
                  

                The conversion of files is solely for file formats prior to version 7.


                Okay, that's what I suspected.

                 


                Some users find that an updated solution introduces a new problem that didn't occur with the previous version.  Therefore, I would use two extensions and switch back and forth.  That way, if a new problem is introduced, the users have a previous version to fall back on.  If not, you would have to go back and create the older working version.  Does that make sense?

                I see. That would be more convenient for the user if there was a problem.

                 

                However, suppose I didn't do that. If I have them keep a backup copy of the old interface and data files, in the "Old" folder, can they can still run those files with the same runtime .exe file? The reason I ask is that it relates to an assumption I've been making, based on the Help docs. That is, I'm assuming I don't have to ship them a new runtime .exe file each time I ship them a new pair of FMP files (interface and data files), even if I use a different extension with the new pair of files, as long as I use the same bind key I did when making the old runtime .exe file. Is that right

                • 5. Re: Upgrading a client's runtime solution
                  TSGal

                  ralvy:

                   

                  Your reasoning is correct.  As long as you use the same bind key, you should be fine.

                   

                  My point with the two files is definitely for you, too.  Unless you can ensure/control that the user keeps a backup file, then there is no reason to change the extension.  However, if you can't ensure, and the user forgets to back up, and the new file crashes, what option do you have?  (That's rhetorical.  No need to answer.  I'm just speaking from experience).

                   

                  TSGal

                  FileMaker, Inc. 

                  • 6. Re: Upgrading a client's runtime solution
                    ralvy
                       Thanks, as usual. This has been very helpful.