0 Replies Latest reply on Dec 3, 2009 2:18 PM by mplatt

    This might help - another bug or just a poor way to handle

    mplatt

      Title

      This might help - another bug or just a poor way to handle

      Post

      From the lack of response from my last post, I think everyone thinks I am a bit crazy. But believe me, anyone working with FMP files around 100mb on a Windows machine will find this useful. I have confirmed my observations and work around on three different machines.

       

      Windows

      FMP 8.5 or 10 Client

      FMP Cache set to 256md

       

      FMP is doing something else inefficiently (Maybe saves a temporary copy to remember a sort state)

       

      Someone PLEASE do a quick test to confirm findings

       

      If you have a file around 100mb unsorted.

      First try doing a sort AND making a single CONTENT CHANGE (just add a space to a text field for one record), then close the file and note the file size, it will almost double. Reopen file (it will be slow), un-sort records AND make a single content change, then close the file and note the file size, it will be back to its original size.

       

      In order to get my templates to work efficiently on windows, I created a script:

       

      Show All Records

      Unsort Records

      Go to Record/Request/Page

      [First]

      Set Field [Clr; ""]

       

      Clr is a field I added solely for this purpose

       

      I set file options to run the script on close and use it within other scripts, where appropriate. This keeps the file size in check and performance consistent. If your file is around 125mb unsorted, good luck.

       

      It is all related to FMP cache limits. I am confident when your file size is more than half the size of your FMP cache preference. Performance seriously suffers.