4 Replies Latest reply on Mar 8, 2009 10:53 AM by FentonJones

    Development, Distribution and Updating ..

    synergy46

      Title

      Development, Distribution and Updating ..

      Post

      I have FM 10 Advanced on OSX.

      I create an application, build it for distribution and distribute it.

       

      Question:

      After Distribution I update some scripts, tweak some layouts, add a table to replace a list lookup etc....

       

      Now I want to distribute these better changes to users.   File Export doesn't seem to do it.  And, of course it needs to be done in a way that will allow the user to RETAIN their existing data.

       

      Also, I read this on the FM web site:  The FileMaker Developer Utilities for Mac OS X and Windows are each platform specific, and each creates a runtime database for that platform only. So the actual runtime database must be created on the platform on which it is intended to be run.

      If your solution will be used in Windows, bind it using the Developer Utilities for Windows.

       

      OK.  That sounds like I have to buy another copy of FM for Windows in order to run the Windows Development Utility?  I have looked on the FM CD I bought (OSX) and there is no Windows development utility.  I think I am just screwed on this.  What is your take?

       

      How would you do it?

       

      Thanks.

       

       

        • 1. Re: Development, Distribution and Updating ..
          vcirilli
            

          >>Now I want to distribute these better changes to users.   File Export doesn't seem to do it.  And, of course it needs to be >>done in a way that will allow the user to RETAIN their existing data.

           

          I've had a FM app out for three years now and what you described above is really a big concern when issuing updates.  Since all the custom programming is retained in the actual file and not in FMP or the Runtime app your users will need to import data from their existing database into the new one to gain your new functionality.  You may want to include a script that handles the importing to make it fool proof for your users.

           

          >> That sounds like I have to buy another copy of FM for Windows

          Not sure about this but it sounds like thats the case. 

           

           

          • 2. Re: Development, Distribution and Updating ..
            synergy46
              

            It sounds like you are saying that I should make a 'clone' of my database and that the 'clone' will contain the scripts, layout changes, lists etc.  Then I would write a script that would import the records from the users previous version into the empty/cloned database?

             

            Do I have that right?

             

            Thanks

            • 3. Re: Development, Distribution and Updating ..
              Jade
                

              synergy46 wrote:

              OK.  That sounds like I have to buy another copy of FM for Windows in order to run the Windows Development Utility?  I have looked on the FM CD I bought (OSX) and there is no Windows development utility.  I think I am just screwed on this.  What is your take?

               


              I have it on good authority (Raybaudi), that the FM CD (OSX) can be used to install FMP on Windows.  Like the Mac version, the Development Tools are part of the insall. Like you, I hope this is the case…:smileyhappy: 

               


              • 4. Re: Development, Distribution and Updating ..
                FentonJones
                  

                Yes, you install from the same installation CD or file onto Windows. The FileMaker installer only shows the version for the current operating system, as that makes sense. If you do not have a Windows computer handy, you can install Windows (retail version, ouch) on an Intel Mac, either in Boot Camp, or via a virtualization app, like Parallels Desktop or VMware (I use the former). Either way works. 

                 

                Another method to consider. There is an method of development known as "separation of data". It involves using 2 files, an "interface" file and a "data" file. The data file has all the real data tables. It has whatever relationships required for lookups, calculations, etc.. But it has few scripts, and minimal layouts. The interface file has all relationships needed, and almost all the scripts. It may have a table or two, for such things as globals, and/or interface graphics. But that's all; it does not have data tables.

                 

                On the relationship graph of the interface file all relevant table occurrences and relationships belonging to the data have been retargeted to the data file. FileMaker does not require a data table to be IN the file to use it. We already use this all the time when working with multiple files, putting a table occurrence of the file on the local file's graph, maybe a layout also. Separation of data simply extends that concept so that all data table occurrences are pointing to an external file.

                 

                Such an interface file can be fairly easily produced by cloning your file, then retargeting the relationships to the original file, which becomes the data file. The layouts and scripts take their instructions from the relationship graph, so they remain the same. Then you can delete the data tables from the interface file. 

                 

                The advantage of this method is that you can distribute minor changes to your file, such as scripts and layouts, simply by giving them a new interface file. Of course, any changes that involve fields, such as calculations, must still be done via the "import all the data into a clone" method. So you'd need both. 

                 

                You can also create a few extra fields in each data file, of each type, text, number, date, etc.. These can then be used as new fields. So just adding a plain field or two later would not require an import.

                 

                If you're distributing a solution it is worth looking in to. It is not as complex as it sounds. Though there a few tricks needed for such things as login accounts, scripts that run with full access, etc.. And, as I said, you will still need the "import all the data," for some updates.

                 

                BTW, custom value lists must remain in the data file; hopefully within a table, so updates will not remove user changes. Value lists which read from fields can be in the interface file, so you can adjust if needed, but can be in either.