4 Replies Latest reply on Mar 3, 2010 7:56 PM by TKnTexas

    Runtime Maintenance.



      Runtime Maintenance.


      I have been working with FMPro10Adv for over a year now.  I have been developing runtimes for my use on my charge where Filemaker Pro is not an approved program, Access is.  I have a runtime for tracking the utilities for our multilocation company.  On a weekly basis I enter to the AP Master table, using the account number as the link between the Utility master and the AP master (with a child file AP detail-gl distribution).  I have been exporting the weekly invoices entered from the child file (for the details) and up loading to the accounts payable program we use.  For two years all has been well. 


      Periodically the only maintenance I have done is to save a compacted version of the file, then replacing it.  Not only am I using this as a training tool to learn to build a runtime application, but it is a way of testing how one will behave in real use. 


      After doing my weekly input, I tried to do the export.  I export 7 fields, 4 from the parent, 3 from the child.  Export is to an Excel worksheet. 

      I select the file to use (always the same name), answer the prompt for overriding with Yes.

      I enter through the next screen.

      As I go to the screen to select the fields, it crashes. 


      I opened and repeated the process.  WIth the same results.  I am using my runtime on XP SP3.  I had to have that export today, critical for my job.  So I copied it to my Mac where I opened it with the Filemaker Pro Adv 10 program.  I used Recover.  Then I did my exports. 


      I put the recovered file on my XP machine.  It opened fine.  I tried an export all was fine. 


      Sorry for the long explanation.  But when I start selling my runtime applications how do my customers handle a problem like this.  Do they have to send it back to the developer?  As the developer what have I overlooked. 

        • 1. Re: Runtime Maintenance.

          If you do a search on "recover" you'll find all kinds of advice on why NOT to ever actually use a recovered file. Did you view the recover log after recovering? Did it report problems? I don't mean to alarm you. Everything "could" be fine. You are, however, if using a recovered file, exposing yourself to risk.



          • 2. Re: Runtime Maintenance.

            I am aware of all of the caveats to the use of a recovered file.  That is not my question. 


            While I am learning ver10, over vers5/6 which I used last actively, I am my own customer.  At home I do my development on my Mac.  I use the "training" application in my paying job.  It is a runtime.  One I have used for over 2 years.  This is the first time I have had to do a recover in order to move forward.


            My question is as a developer what did I miss.  If develop a runtime for commercial sale my customers are not going to have full versions.  Is there recourse to come back to me to repair the file.  Do I build data moving scripts to move their data to a clone?  Currently I am training with the data-separation model.


            If I deploy this way, and there is a failure such as I experienced last week, is it the data-file or the front end file that will need to be replaced?  Reading about recovery did not answer my questions.

            • 3. Re: Runtime Maintenance.
              Steve Wright

              Filemaker runtimes do have built in recovery..  


              Hold down CTRL + SHIFT on windows whilst opening the file, it will prompt which files to recover.


              What we do is always have a clone copy of the database file in case of issues like this, then if a recover is needed for any reason, the client can re-import their data into a fresh (non recovered) file.


              RE: Replacing a file, it depends which file has the issue and which file needs recovering.

              • 4. Re: Runtime Maintenance.

                Thanks.  I will investigate that.  I do keep a clone.  I need to automate the data transfer between the two.