Hi All,

Does anyone have any suggestions on how to compare a database to a copy of
itself, compacted vs. uncompacted? I have a vendors product that is
currently balooning their included .mdb. I've got a copy of the original
(116MB) and a copy I compacted (1.6MB). I'd like to see if I can identify
which objects might be at issue.

Any suggestions are definitely appreciated.

Ciao

On Thu, 8 Nov 2007 12:05:51 -0600, "Tony" <|(E-Mail Removed)|>
wrote:

There are no tools that I know of that can report the size of
uncompacted objects.

Typically the bloat is in tables where many records are repeatedly
added and removed, for example temp tables and report tables.

Fortunately you can buy 116GB hard drives for less than USD116, so it
may not be worth worrying too much about.

-Tom.


>Hi All,
>
>Does anyone have any suggestions on how to compare a database to a copy of
>itself, compacted vs. uncompacted? I have a vendors product that is
>currently balooning their included .mdb. I've got a copy of the original
>(116MB) and a copy I compacted (1.6MB). I'd like to see if I can identify
>which objects might be at issue.
>
>Any suggestions are definitely appreciated.
>
>Ciao
>

Tom,

Thanks for your reply. I think what's happening is what you've suggested;
records are being queued because they cannot be written correctly to the
database. Because the vendor can't or chooses not to figure it out, I"m
stuck with the task of iguring it out. And, the database in question is
part of our spam filtering application and grows quite quickly because each
time we have to whitelist an address using the vendors UI, the db jumps
1.5 - 2 MB. So, no matter how inexpensive disk space is (and hom many times
we compact/repair) it's still not a good situation.

Anyway, thanks again for the post & I'll forge forward.

Ciao

"Tom van Stiphout" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> On Thu, 8 Nov 2007 12:05:51 -0600, "Tony" <|(E-Mail Removed)|>
> wrote:
>
> There are no tools that I know of that can report the size of
> uncompacted objects.
>
> Typically the bloat is in tables where many records are repeatedly
> added and removed, for example temp tables and report tables.
>
> Fortunately you can buy 116GB hard drives for less than USD116, so it
> may not be worth worrying too much about.
>
> -Tom.
>
>
>>Hi All,
>>
>>Does anyone have any suggestions on how to compare a database to a copy of
>>itself, compacted vs. uncompacted? I have a vendors product that is
>>currently balooning their included .mdb. I've got a copy of the original
>>(116MB) and a copy I compacted (1.6MB). I'd like to see if I can identify
>>which objects might be at issue.
>>
>>Any suggestions are definitely appreciated.
>>
>>Ciao
>>

"Tony" <|(E-Mail Removed)|> wrote in
news:(E-Mail Removed):

> Does anyone have any suggestions on how to compare a database to a
> copy of itself, compacted vs. uncompacted? I have a vendors
> product that is currently balooning their included .mdb. I've got
> a copy of the original (116MB) and a copy I compacted (1.6MB).
> I'd like to see if I can identify which objects might be at issue.
>
> Any suggestions are definitely appreciated.

Loop through the TableDefs collection of the MDB before compacting
and record the number of records for each table. After the compact,
do the same thing.

If the compact loses data, Access will tell you, and there will be a
compact errors table.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/