Multiple decompile/compact keeps reducing file size?

[Jeff]

I have a db that has a couple of times closed Access completely when Saving
work.

So I usually compact and decompile and this seems to fix the problem. But
not his time. It has come back again.

But my query is this. How come I can keep reducing file size?

I decompiled, recompiled and compacted the db 3 times and each time the
file size reduced. First time from 13.5 MB to 7.5 MB. Second time down a few
Kb to just below 7.5 MB. Third time down another 2MB to 5.4 MB.

What!!!

Jeff Pritchard
________________
Asken Research Pty. Ltd.
Access Database Developers
http://www.asken.com.au

[Tom van Stiphout]

On Wed, 13 Dec 2006 10:57:54 +1000, "Jeff"
<je************@asken.com.auwrote:

When you continued this process, did it eventually go negative?

-Tom.

>I have a db that has a couple of times closed Access completely when Saving
work.

So I usually compact and decompile and this seems to fix the problem. But
not his time. It has come back again.

But my query is this. How come I can keep reducing file size?

I decompiled, recompiled and compacted the db 3 times and each time the
file size reduced. First time from 13.5 MB to 7.5 MB. Second time down a few
Kb to just below 7.5 MB. Third time down another 2MB to 5.4 MB.

What!!!

Jeff Pritchard
________________
Asken Research Pty. Ltd.
Access Database Developers
http://www.asken.com.au

[Jeff]

Hey that's a good idea. If I keep doing it will it increase the size of my
HD?

Jeff

"Tom van Stiphout" <no*************@cox.netwrote in message
news:5q********************************@4ax.com...

On Wed, 13 Dec 2006 10:57:54 +1000, "Jeff"
<je************@asken.com.auwrote:

When you continued this process, did it eventually go negative?

-Tom.

>>I have a db that has a couple of times closed Access completely when
Saving
work.

So I usually compact and decompile and this seems to fix the problem. But
not his time. It has come back again.

But my query is this. How come I can keep reducing file size?

I decompiled, recompiled and compacted the db 3 times and each time the
file size reduced. First time from 13.5 MB to 7.5 MB. Second time down a
few
Kb to just below 7.5 MB. Third time down another 2MB to 5.4 MB.

What!!!

Jeff Pritchard
________________
Asken Research Pty. Ltd.
Access Database Developers
http://www.asken.com.au

[Tom van Stiphout]

On Thu, 14 Dec 2006 08:12:49 +1000, "Jeff"
<je************@asken.com.auwrote:

The only thing that comes to mind is the double-compact that is
sometimes necessary with replicated databases. Are you sure your
database is not corrupt?

-Tom.

>Hey that's a good idea. If I keep doing it will it increase the size of my
HD?

Jeff

"Tom van Stiphout" <no*************@cox.netwrote in message
news:5q********************************@4ax.com.. .

>On Wed, 13 Dec 2006 10:57:54 +1000, "Jeff"
<je************@asken.com.auwrote:

When you continued this process, did it eventually go negative?

-Tom.

>>>I have a db that has a couple of times closed Access completely when
Saving
work.

So I usually compact and decompile and this seems to fix the problem. But
not his time. It has come back again.

But my query is this. How come I can keep reducing file size?

I decompiled, recompiled and compacted the db 3 times and each time the
file size reduced. First time from 13.5 MB to 7.5 MB. Second time down a
few
Kb to just below 7.5 MB. Third time down another 2MB to 5.4 MB.

What!!!

Jeff Pritchard
________________
Asken Research Pty. Ltd.
Access Database Developers
http://www.asken.com.au

[Jeff]

No, I am not. But this is the only symptom if it is. And this is not a
replicated database.

Really, this is the only problem that I have with this database. I have had
it with others but decompiling and compacting a couple of times seems to fix
it.

It's a bit of a mystery. I suppose I wait to see if it occurs again.

Jeff

"Tom van Stiphout" <no*************@cox.netwrote in message
news:jd********************************@4ax.com...

On Thu, 14 Dec 2006 08:12:49 +1000, "Jeff"
<je************@asken.com.auwrote:

The only thing that comes to mind is the double-compact that is
sometimes necessary with replicated databases. Are you sure your
database is not corrupt?

-Tom.

>>Hey that's a good idea. If I keep doing it will it increase the size of my
HD?

Jeff

"Tom van Stiphout" <no*************@cox.netwrote in message
news:5q********************************@4ax.com. ..

>>On Wed, 13 Dec 2006 10:57:54 +1000, "Jeff"
<je************@asken.com.auwrote:

When you continued this process, did it eventually go negative?

-Tom.
I have a db that has a couple of times closed Access completely when
Saving
work.

So I usually compact and decompile and this seems to fix the problem.
But
not his time. It has come back again.

But my query is this. How come I can keep reducing file size?

I decompiled, recompiled and compacted the db 3 times and each time the
file size reduced. First time from 13.5 MB to 7.5 MB. Second time down a
few
Kb to just below 7.5 MB. Third time down another 2MB to 5.4 MB.

What!!!

Jeff Pritchard
________________
Asken Research Pty. Ltd.
Access Database Developers
http://www.asken.com.au

[Albert D. Kallal]

Well, eventually, the size reduction must stop.

Here is what is going on if you are wondering:

when you first de-compile, you should hold down the shift key. And, you
should EXIT the database right away.

You MUST MAKE SURE that no code runs!!!

After you exit, you re enter (without the de-compile). Also, as mentioned,
you MUST hold down the shift key if you have ANY code that runs (ignore that
shift key advice if no start up code exists).

Ok...no, do a compact and repair..(and again..MAKE SURE no start code runs).
At this point you file size will be as SMALL AS IT can get. Exit, and take a
look. You will have no junk (that decompile removed) and you will have NO
object code. You will be amazed..and the mdb file will be as SMALL as it
will ever get.

In you case, when you do a de-compile, all of the code junk is still there.
You compact..and it gets all cleaned out...a huge drop in size..however, if
you have any start-up code that runs...it gets compiled..and when you
compact/repair.....you STILL HAVE some reduction in size available due to
SOME code being compiled. So, doing a compact and repair , and then again a
decompile removes this compile code (but, clearly not as much junk is left
over as compared to the first de-compile).

So, try the above sequence and always exit the database right after you
de-compile..

post back here for the people as to how the above went....

So, critical here...is exit right after a de-compile..and then re-enter.
And, in ALL CASES DO NOT let any code run...so, that might mean in all of
the above cases you MUST use the shift key....

--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
pl*****************@msn.com

[David F Cox]

Thanks, Albert, today I have learned something.

David F. Cox

"Albert D. Kallal" <Pl*******************@msn.comwrote in message
news:GYlgh.477143$1T2.412631@pd7urf2no...

Well, eventually, the size reduction must stop.

Here is what is going on if you are wondering:

when you first de-compile, you should hold down the shift key. And, you
should EXIT the database right away.

You MUST MAKE SURE that no code runs!!!

After you exit, you re enter (without the de-compile). Also, as mentioned,
you MUST hold down the shift key if you have ANY code that runs (ignore
that shift key advice if no start up code exists).

Ok...no, do a compact and repair..(and again..MAKE SURE no start code
runs). At this point you file size will be as SMALL AS IT can get. Exit,
and take a look. You will have no junk (that decompile removed) and you
will have NO object code. You will be amazed..and the mdb file will be as
SMALL as it will ever get.

In you case, when you do a de-compile, all of the code junk is still
there. You compact..and it gets all cleaned out...a huge drop in
size..however, if you have any start-up code that runs...it gets
compiled..and when you compact/repair.....you STILL HAVE some reduction in
size available due to SOME code being compiled. So, doing a compact and
repair , and then again a decompile removes this compile code (but,
clearly not as much junk is left over as compared to the first
de-compile).

So, try the above sequence and always exit the database right after you
de-compile..

post back here for the people as to how the above went....

So, critical here...is exit right after a de-compile..and then re-enter.
And, in ALL CASES DO NOT let any code run...so, that might mean in all of
the above cases you MUST use the shift key....

--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
pl*****************@msn.com

[deluxeinformation]

Albert D. Kallal wrote:

So, critical here...is exit right after a de-compile..and then re-enter.
And, in ALL CASES DO NOT let any code run...so, that might mean in all of
the above cases you MUST use the shift key....

This is quite interesting. I took this a step further since I do not
like to leave my code in a decompiled state. I made two copies of an
..adp file as follows:

adp1 started out at 20,955,648 bytes.

With copy 1:
decompile + shift
compile
compact/repair
exit
resulted in a 14,409,216 byte compiled file.

With copy 2:
decompile + shift
exit
start + shift
compact/repair + shift
exit
resulted in a 10,332,672 byte decompiled file (much smaller, but
decompiled)

opened copy 2 again + shift
compile
compact/repair + shift
exit
resulted in a 14,439,936 byte compiled file.

Interestingly, it appears that decompiling, exiting, restarting, and
compiling results in a larger compiled file than simply decompiling and
compiling even though no code was run in any case. Also it appears
that exiting and restarting actually hinders the process of creating
the smallest compiled file but helps the process of creating the
smallest de-compiled file. Interesting.

Bruce

[Jeff]

After reading my post I realized that I didn't mention the actions in the
right sequence. I always decompile first, then compact, then reopen and
compile the database. At no time do I allow any startup code to run. But I
still got these strange results.

So I investigated further and with another database follow the some process.
File sizes over 2 iterations went down from about 11MB to 7,488K after the
final compile.

Interestingly, at this point I noticed that if I then decompiled it went
back up to 7,556, then after a compact down to 3,784 and then after the
final compile back up to 7,492.

I did the sequence again and I was back to 7,488.

I did it again and I was back to 7,492, and each time after that it seems to
remain at 7,492.

Mmmm?

Jeff

"Albert D. Kallal" <Pl*******************@msn.comwrote in message
news:GYlgh.477143$1T2.412631@pd7urf2no...

Well, eventually, the size reduction must stop.

Here is what is going on if you are wondering:

when you first de-compile, you should hold down the shift key. And, you
should EXIT the database right away.

You MUST MAKE SURE that no code runs!!!

After you exit, you re enter (without the de-compile). Also, as mentioned,
you MUST hold down the shift key if you have ANY code that runs (ignore
that shift key advice if no start up code exists).

Ok...no, do a compact and repair..(and again..MAKE SURE no start code
runs). At this point you file size will be as SMALL AS IT can get. Exit,
and take a look. You will have no junk (that decompile removed) and you
will have NO object code. You will be amazed..and the mdb file will be as
SMALL as it will ever get.

In you case, when you do a de-compile, all of the code junk is still
there. You compact..and it gets all cleaned out...a huge drop in
size..however, if you have any start-up code that runs...it gets
compiled..and when you compact/repair.....you STILL HAVE some reduction in
size available due to SOME code being compiled. So, doing a compact and
repair , and then again a decompile removes this compile code (but,
clearly not as much junk is left over as compared to the first
de-compile).

So, try the above sequence and always exit the database right after you
de-compile..

post back here for the people as to how the above went....

So, critical here...is exit right after a de-compile..and then re-enter.
And, in ALL CASES DO NOT let any code run...so, that might mean in all of
the above cases you MUST use the shift key....

--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
pl*****************@msn.com