4 Replies Latest reply on May 15, 2012 2:38 PM by philmodjunk

    Upgrading runtime solution help.

    JCPython

      Title

      Upgrading runtime solution help.

      Post

      I have my runtime that i packaged and sent to a few testers, once bugs were found and a few changes were made to my master copy i want to issue out the new updated runtime, BUT i need the testers to be able to import their data that they already enetered in on the first copy of the runtime.

       

      right now i have a simple import script that is setup to import each table from the old file to the new file...but im having trouble making it easy for the end user to be able to do this with little to none computer expirience, i want it to be as automatic as possible.

       

      so lets say i package up the new runtime and mail it out tonight, the user then unzips the file, and because i cant find a working filemaker installer, the user must ake the runtime directory file and manually move it to their c:\ drive.

       

      after that is done i need my import script to work from the new runtime, but a part of the script thats missing is to automatically locate the old .USR file in the old directory

       

      i use the same bindkey when making the different updates to the runtime, is that ok to do? cant i just copy the new .usr file to overwrite the old one?isnt the usr file were the records are store? or is it the layout as well.

       

      sorry for all the questions but ive been getting really lost the past week with this and im trying to understand the purpose of the bindke and .usr files (or in my case .HPR files)

       

      im just trying to find the simplest way to update my runtime to the end users, i will often be making changes to the layouts as well as the tables. so the seperation model isnt really for me.

       

       

      Thanks for any input.

        • 1. Re: Upgrading runtime solution help.
          philmodjunk

          A USR file stores both layouts and data--assuming you have a one file solution and you are using the default file extension for the database files used in your runtime solution. If you used data separation, you would have at least two USR files--one with data and one with the layouts/scripts/etc. If your updates are just to the inteface, you can email your users just the .usr file for the interface and have them (or an installer) copy the file into their existing folder and it can then replace the old file with the new.

          With data separation, you'll only need to move data if you modify the data file's design.

          Here's a strategy you can play with for updating files that contain the data tables used in your solution:

          When you produce your runtime, include an extra file, call it "data update" or something. It's just a place holder for the update file that you might distribute in the future. Create a script in your actual data file that does a show all records for each table in the file and then uses perform script to perform a script in the "data update" file. This script then uses a series of Import Records and Set Next Serial value steps to import your data from every table in the data file. Make sure that the external data source reference used by this perform script step is a relative path reference. For simplicity, this file can be a clone of the actual data file.

          Now include this exact same script in any updated copy you distribute. The user can drag and drop the file into their solution folder as it will only replace the place holder file. The user then clicks a button in their original file to run the update scripts. The final steps of the update script in the data update file are to close the original data file and then use save a copy as, to save a copy of the updated file that is now loaded with data from the user's original file to the original file name of the data file to overwrite it and replace it with the new version.

          Please note that I haven't tested this idea out so give it a try and let me know how it goes.

          • 2. Re: Upgrading runtime solution help.
            JCPython

            Thanks Phil,

            ill be honest my solution is filled with over 50 tables and possibly over 200 scripts, its getting a little over welming for me since i have tried so many different schemes for different features and some work some dont, but i got bits and pieces left over and the whole thing needs to be tidied up, im gonna try your idea later on after i get that cleaned up and things are more stable, but i need to get this update out tonight or tomorrow and i dont think its a good idea for me to jump in to something new and possibly i  could screw something up.

             

            The way i have it setup now is when the user places the directory of the new runtime and opens the exe, they then can go press a button that runs a script that they will locate the .USR file from the old runtime directory and then perform an imprt script with a SHOW ALL, DELETE ALL AND IMPORT ALL TABLES THEN SET SERIAL VALUES.

            Thank you for explanning the importance of the .usr files.

             

            A USR file stores both layouts and data--assuming you have a one file solution and you are using the default file extension for the database files used in your runtime solution. If you used data separation, you would have at least two USR files--one with data and one with the layouts/scripts/etc. If your updates are just to the inteface, you can email your users just the .usr file for the interface and have them (or an installer) copy the file into their existing folder and it can then replace the old file with the new.

             

            That makes me start to think that i may be able to use it after all, i didnt think it was possible to edit the data structure using that method.

             

            ill play around with things tonight and report back here...i dont know what ill do but im getting very overwhelmed lol. ill try and find a example file of the seperation model as well and see what i can learn from it.

             

            • 3. Re: Upgrading runtime solution help.
              philmodjunk

              Thought I'd already shared this thread on data separation with you in an earlier thread on how to manage updates: Convert to Seperation Model

              • 4. Re: Upgrading runtime solution help.
                philmodjunk

                And with sending out updated files, the file sent should be a clone or a "near clone" with no user entered data present. Since you will copy all data into this file from the original, there's no need for any 'delete all' steps in the update process.