1 Reply Latest reply on Aug 24, 2011 11:33 AM by philmodjunk

    Runtime Update, Data Separation Models, Pros and Cons -- Do I understand?

    rgnant_1

      Title

      Runtime Update, Data Separation Models, Pros and Cons -- Do I understand?

      Post

      Let's see if I have this right...

      If I create an update to an "integrated file", either in FM or in a runtime solution, I can pass this update on to the user.  The user can open the New file and I can write scripts that will import all records from the Old into the New.  Then, the user can trash the Old... and should probably rename the New as Old for the next time there is an update.  (I have not been able to find a way to change a file name with a FM command.)

      In a data separation model, the importing can be skipped because the NewProgram file will simply read from the Old Data file.  BUT,  if new fields are required they must be put into a New Data file.  Then, both a new Program and a new Data file must be delivered.  The New Program file can simply replace the Old Program file, but the New Data file has to import from the Old Data file.

      Do I understand this correctly?  If so, it is because Phil Modjunk has the patience of a Saint.  If I don't understand it, it isn't his fault.

        • 1. Re: Runtime Update, Data Separation Models, Pros and Cons -- Do I understand?
          philmodjunk

          You've got the basic idea. The beauty of a data separation model is that updates to the interface tend to be much more common than updates to the data file.

          To rename files is not a built in Filemaker function but you can use batch files in windows or Applescripts on Macs to do this. You can also use Insert File to insert a file into a container field and then use Export Field Contents to create a new cop of the file with a new file name. You can also use Save a Copy as to save a copy of your current file, but with a new file name.