Excessive Memory on Normal dB

[Linda & Jason]

I have created a dB that appears to be normal in all aspects. It has 1400
fields, 900+ Scripts and NO DATA INPUT or Photographs. (Not Yet Anyway)

Why would I pick up 67 MB of used memory in what should be under 5 MB?

Has anyone else experienced this and if so, is there a solution to removing
this excess successfully?

Thanks In Advance..

Jason

[Bridget Eley]

Hi Jason

If you have ever created records in it (to test calcs and scripts) then
deleted them, they may have created lots of unused blocks. Try saving the
file as a compressed copy or clone (if you opt for the latter, you will need
to import at least record from the old copy to restore any global field
values).

Bridget Eley

in article [email]DbydnUl0Ftzf5dOiXTWJhg@shawneelink.net[/email], Linda & Jason at
[email]towersq@shawneelink.net[/email] wrote on 29/8/03 7:45 AM:

> I have created a dB that appears to be normal in all aspects. It has 1400
> fields, 900+ Scripts and NO DATA INPUT or Photographs. (Not Yet Anyway)
>
> Why would I pick up 67 MB of used memory in what should be under 5 MB?
>
> Has anyone else experienced this and if so, is there a solution to removing
> this excess successfully?
>
> Thanks In Advance..
>
> Jason
>
>

[Bridget Eley]

Also, when you create a runtime, you are affectively including a parred down
version of the filemaker pro application in the size of the solution.

Bridget Eley

in article BB74B8B3.2BE5%bridgeteley@ihug.com.au, Bridget Eley at
[email]bridgeteley@ihug.com.au[/email] wrote on 29/8/03 8:00 AM:

> Hi Jason
>
> If you have ever created records in it (to test calcs and scripts) then
> deleted them, they may have created lots of unused blocks. Try saving the
> file as a compressed copy or clone (if you opt for the latter, you will need
> to import at least record from the old copy to restore any global field
> values).
>
> Bridget Eley
>
> in article [email]DbydnUl0Ftzf5dOiXTWJhg@shawneelink.net[/email], Linda & Jason at
> [email]towersq@shawneelink.net[/email] wrote on 29/8/03 7:45 AM:
>

>> I have created a dB that appears to be normal in all aspects. It has 1400
>> fields, 900+ Scripts and NO DATA INPUT or Photographs. (Not Yet Anyway)
>>
>> Why would I pick up 67 MB of used memory in what should be under 5 MB?
>>
>> Has anyone else experienced this and if so, is there a solution to removing
>> this excess successfully?
>>
>> Thanks In Advance..
>>
>> Jason
>>
>>

>

[Tom Fitch]

900 scripts... ok, maybe. But 1400 fields???
That's not what I'd call "normal."

Tom Fitch
Fitch & Fitch
Portland, Oregon

"Linda & Jason" <towersq@shawneelink.net> wrote:

> I have created a dB that appears to be normal in all aspects. It has 1400
> fields, 900+ Scripts and NO DATA INPUT or Photographs. (Not Yet Anyway)
>
> Why would I pick up 67 MB of used memory in what should be under 5 MB?

[John Weinshel]

Too many fields (or layout [unless they are filled with imported graphics]},
scripts or value lists, while possibly indicating poor design, are not
likely to plump up the file. I like Bridget's explanation a lot better--
unrecovered memory blocks left over from testing, where the tests included a
bunch of jpg's.

But I also agree that the huge number of fields and scripts may indicate bad
data modelling.

--
John Weinshel
Datagrace
Vashon Island, WA
(206) 463-1634
Associate Member, Filemaker Solutions Alliance


"Kevin Hayes" <kevin-noSPam-bhayes@rogers-noSPam-.com> wrote in message
news:MPG.19b9118f32b80f84989785@news.ca.nortel.com ...

> In article <DbydnUl0Ftzf5dOiXTWJhg@shawneelink.net>,
> [email]towersq@shawneelink.net[/email] says...

> > I have created a dB that appears to be normal in all aspects. It has

1400

> > fields, 900+ Scripts and NO DATA INPUT or Photographs. (Not Yet

Anyway)

> >
> > Why would I pick up 67 MB of used memory in what should be under 5 MB?
> >
> > Has anyone else experienced this and if so, is there a solution to

removing

> > this excess successfully?
> >

>
> 1400 fields??? That probably had something to do with it. Also, the
> suggestion of saving a compressed copy may help.
>
> I'm very curious, so pardon me for asking, but what kind of database has
> 1400 fields?
>