Why the size become smaller after the fix of corruption?

[LeonC]

The corrupted access database file was 200MB, but after it was fixed by
Access, it was reduced to 75 MB.

My question: is there any other way to compress the database ( say 200
MB ) to 75 MB? or there is something wrong inside this corruptied
database file?

Unfortunately I can't remember the size of the correct database file
before it was corrupted... is it possible that the corruption cause a
boost of the size?

[Scott McDaniel]

On 21 Jul 2006 03:51:46 -0700, "LeonC" <li*********@gmail.comwrote:

>The corrupted access database file was 200MB, but after it was fixed by
Access, it was reduced to 75 MB.

My question: is there any other way to compress the database ( say 200
MB ) to 75 MB? or there is something wrong inside this corruptied
database file?

You should Compact and Repair your database regularly. You can set your database to Compact on Close (look through the
Tools - Options settings for this).

>Unfortunately I can't remember the size of the correct database file
before it was corrupted... is it possible that the corruption cause a
boost of the size?

Sure it does. Corrupt dbs are often a LOT bigger than their "normal" size.

There's also a Decompile switch you can use to help manage this. See this link for useage, and make sure to click on the
Michael Kaplan link found there for full information before using this switch:

http://www.mvps.org/access/bugs/bugs0008.htm

When I use /Decompile, I always (a) decompile, (b) compile (VBA Editor, click Tools - Compile), then (c) Compact and
Repair. Don't know if this is the "recommended" method, but it's always worked for me.

As always, make SURE to make a copy of your original db before trying any of this.

Scott McDaniel
scott@takemeout_infotrakker.com
www.infotrakker.com

[David W. Fenton]

Scott McDaniel <scott@NoSpam_Infotrakker.comwrote in
news:k6********************************@4ax.com:

You should Compact and Repair your database regularly. You can set
your database to Compact on Close (look through the Tools -
Options settings for this).

This is a very bad idea, because some forms of corruption can lose
data. If you have Compact On Close turned on, you don't get a chance
to close without compacting.

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

[David W. Fenton]

Scott McDaniel <scott@NoSpam_Infotrakker.comwrote in
news:k6********************************@4ax.com:

You should Compact and Repair your database regularly. You can set
your database to Compact on Close (look through the Tools -
Options settings for this).

Oh, and another thing:

If your application is properly designed, you'll only be compacting
the front end, anyway, and there's no data in that, so I see Compact
On Close as completely and utterly useless.

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

[David W. Fenton]

Scott McDaniel <scott@NoSpam_Infotrakker.comwrote in
news:k6********************************@4ax.com:

When I use /Decompile, I always (a) decompile, (b) compile (VBA
Editor, click Tools - Compile), then (c) Compact and Repair. Don't
know if this is the "recommended" method, but it's always worked
for me.

You should:

1. decompile.

2. in a different Access instance, compact.

3. compile.

4. compact.

It's essential to not skip step 2 in order to clean out the
discarded code pages. I don't know that Access would ever re-use
discarded pages in recompiling, but if you've compacted, there's no
possibility of that happening accidentally, as the discarded
compiled code pages no longer exist.

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

[Scott McDaniel]

Thanks for the clarifications, David.

On Fri, 21 Jul 2006 08:01:15 -0500, "David W. Fenton" <XX*******@dfenton.com.invalidwrote:

>Scott McDaniel <scott@NoSpam_Infotrakker.comwrote in
news:k6********************************@4ax.com :

>When I use /Decompile, I always (a) decompile, (b) compile (VBA
Editor, click Tools - Compile), then (c) Compact and Repair. Don't
know if this is the "recommended" method, but it's always worked
for me.

You should:

1. decompile.

2. in a different Access instance, compact.

3. compile.

4. compact.

It's essential to not skip step 2 in order to clean out the
discarded code pages. I don't know that Access would ever re-use
discarded pages in recompiling, but if you've compacted, there's no
possibility of that happening accidentally, as the discarded
compiled code pages no longer exist.

Scott McDaniel
scott@takemeout_infotrakker.com
www.infotrakker.com

[Scott McDaniel]

On Fri, 21 Jul 2006 07:59:25 -0500, "David W. Fenton" <XX*******@dfenton.com.invalidwrote:

>Scott McDaniel <scott@NoSpam_Infotrakker.comwrote in
news:k6********************************@4ax.com :

>You should Compact and Repair your database regularly. You can set
your database to Compact on Close (look through the Tools -
Options settings for this).

Oh, and another thing:

If your application is properly designed, you'll only be compacting
the front end, anyway, and there's no data in that, so I see Compact
On Close as completely and utterly useless.

True. The backend would rarely be opened and closed in a properly designed app ... better to have this done manually on
a set schedule (along with daily backups, I presume).

Scott McDaniel
scott@takemeout_infotrakker.com
www.infotrakker.com