File is growing larger and slower

[Tom Kennedy]

I am testing a small amount of data in a FM file on a 2009 MacBook Pro with 4Gb of memory and a 128Gb Solid state drive. The file was 60GB on 9/18 and is now 155.7Gb. I have been entering very little data during this time. I have been working with this file for over a year and a half without anything like this happening. Because I am not entering much data the file has been around 50 to 60Gb for the last year.

The slowness occurred at during this same period and I am not talking about slowness regarding processing data. When I make the window larger by dragging the lower right hand corner, it takes approximately 2 seconds to complete.

I have run FMDiff to see if there was any corruption and it said there was no apparent corruption. I have copied the file to a compacted copy and it reduced the file from 155.7GB to 84.4Gb which is still over 24Gb larger than 2 weeks ago. And the speed is still slow.

Any Ideas?

[Søren Dyhr]

In your present 84 post to this forum, have they all been biased towards layout crincles ... you have nowhere been given any evidence of how normalized your structure actually might be, other than you might have a soft spot for hointing summary fields a bit casual.

But by and large is everything focused in the presentation layer - why?

--sd

[Tom Kennedy]

Thanks for the advice. I found out there is a section for corruption under Brain Food (who would have thought).

Update: I did a recovery on the file and got a pretty intimidating message that started off with "Warning: problems were detected while recovering the database. Any advice or ideas of what products, articles, etc. I might consider to get rid of this problem? I will try to be a better bird.

FYI - If you visit Texas you might not use this type of wording "you might have a soft spot for hointing summary fields a bit casual". We Texans may not know what that means, but we still might take offense. I am too old to give you any trouble, but some of the young ones are pretty sensitive. I did solve my problem, after an expensive and unproductive visit with FM, by creating an additional layout - I basically gave up.

[Lee Smith]

Hi Tom,

"you might have a soft spot for hointing summary fields a bit casual"

It doesn't mean anything in California either, in fact a Google search for [color:blue]hointing return "did you mean hunting'. Maybe it lost something in the translation?

Lee

[bruceR]

I am testing a small amount of data in a FM file on a 2009 MacBook Pro with 4Gb of memory and a 128Gb Solid state drive. The file was 60GB on 9/18 and is now 155.7Gb.

A 156GB file is on a 128GB SSD? Seems doubtful.

[Søren Dyhr]

Well I do not know what it's called, I'm indeed no Hemmingway ... Throwing something over a fence, while not being able to see where it's landing. Hoping for the best. "Casual" is not covering particular well here, since it's and established method - a sort of exit strategy ... not too far from bluffing in poker. It's the thing a burglar does when the alarm goes. He throws (apparently not hointing) the bag out of an open window not expecting a police officer outside catching it.

--sd

Edited October 5, 2009 by Guest

[IdealData]

The only real answer is to find a backup that is not damaged and import the data from the current file.

Any corruption may not become evident until later, so take action now,

You could also consider rebuilding your FM file from scratch if it's not too complex.

Edited October 5, 2009 by Guest

[Tom Kennedy]

It should have been:

The file was 60Mb on 9/18 and is now 155.7Mb.

[Tom Kennedy]

I just purchased FM Pro Migrator from .com to do a rebuild. Has anyone used this product before?

[Tom Kennedy]

Update:

The Recover message was caused by two graphics. I was told that this error message has something to do with element grouping and boundBox. I was able to read the Recover log to determine the layouts in question. And then by deleting objects on one of the layouts and running Recover on the file after each deletion, I was able to locate the problem.

The slowness was caused by two container fields located in a related record. These fields also added about 17Mb to the file. And they were working container fields that I was not clearing before I left the file.

Thanks for everyone's help.

[Søren Dyhr]

Graphics in a layout and data arriving from a container field, should in my humble opinion be very different matters.

If these few directions are followed to the point wouldn't your solution land itself in the mess expirienced, methinks?

--sd