AnsweredAssumed Answered

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

Question asked by mplatt on Dec 3, 2009

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.

Outcomes