decompile in Access 2002?

[TR]

Re: decompile in Access 2002?

I've tried this several times, starting with two different shortcuts to initiate
the decompile (one that includes the target database to be decompiled, the other
that simply starts access with the decompile switch, then I open the target
database.
Started with a 57MB file.
Decompiled.
Ran repair and compact (from Access 2002 menus).
Database grows in size. In fact, it grows with every iteration of the above.
This particular database grows by about 6-8 MB everytime. Now up to 118 mb. Good
thing I'm working with a copy.
I read the articles you posted. Why would the database just grow and grow with
every decompile?


"Michael (michka) Kaplan [MS]" wrote:
[color=blue]
> "bebelino" <a.b@c.d> wrote...
>[color=green]
> > Well then, could you please tell what the right steps are?[/color]
>
> Well, if you look at http://trigeminal.com/usenet/usenet004.asp and think
> about what it is saying and then also look at
> http://trigeminal.com/usenet/usenet023.asp and do the same, then you will
> see that for the smallest possible file, you must:
>
> 1) decompile the db
> 2) Compact it through the ACCESS, not DAO/JRO/Jet.
>
> to get the SMALLEST possible db. If you compile any other way then you will
> not get a clean defragmented project. And if you "compile all/save all" then
> you are causing there to be two complete sets of streams (the canonical text
> and the binary compiled information) and you will have the largest possible
> "valid" information. What you get rid of is any bogus streams that are
> hanging around (see the article point #2 talking about project size).
>
> Now, if you look at an average Access db that you have not recently
> decompiled, it is probably:
>
> A) Not entirely compiled (see the article which mentions there are 11
> compliation states!)
> B) Some invalid streams that are just hanging around in the database in
> dirty objects
> C) A fragmented project
>
> and then if you do the original steps given here that involve doing a
> compile all/save all, it is possible that the number of items you save by
> fixing (B) and (C) will be less than the space taken in the fix for (A). So
> you end up with a technically "bigger" file. But that is expected and has
> nothing to do with the sort of issue that causes people to recommend
> /decompile to save space.
>
> In fact, if you compare a completely decompiled db (no compiled binary
> project) and an MDE (no canonical text), you will see that the MDE is
> bigger. Compiled code takes up SPACE, more space than the text upon which it
> is based, in VBA.
>
> Does this mean you should not compile? Of course not! Compiling is important
> for good performance.
>
> INSTEAD, it is better to think of /decompile as it is described at
> http://trigeminal.com/usenet/usenet004.asp and realize that you will
> eliminate all of the WASTED space for dead information that is just haning
> around, building upon a database like barnacles on an old ship's hull. If
> you end up with a file that is bigger then that means that you were not
> entirely compiled and possibly you did not have much in the way of wasted
> space anyway.
>
> --
> MichKa [MS]
> NLS Collation/Locale/Keyboard Development
> Globalization Infrastructure and Font Technologies
>
> This posting is provided "AS IS" with
> no warranties, and confers no rights.[/color]

[TR]

Re: decompile in Access 2002?

Hi David,
Certainly clear directions. I followed them explicitly, using a copy of
the nwind.mdb. Disabled the startup form and custom menu, compacted,
then proceeded. Grows incrementally with each iteration.
Beginning size: 1980 kb
1st iteration: 2096 kb
2nd iteration: 2220 kb



"David W. Fenton" wrote:
[color=blue]
> a.b@c.d (bebelino) wrote in
> <gphjovs87b5n5e cnaait7aq179lql r4qkf@4ax.com>:
>[color=green]
> >On Sun, 12 Oct 2003 10:39:54 -0700, "Michael \(michka\) Kaplan
> >[MS]"
> ><michkap@onlin e.microsoft.com > wrote:
> >[color=darkred]
> >>Actually /decompile WILL decrease size, when it is done
> >>correctly. All of the steps posted in this thread have been
> >>wrong, thus the different results.[/color]
> >
> >Well then, could you please tell what the right steps are?[/color]
>
> Michael's response is recommended reading, of course, but he's not
> entirely explicit on the reason why your steps were wrong.
>
> Here's the proper decompile cycle:
>
> 1. compact your database.
>
> 2. decompile it and close the instance of Access used to decompile.
>
> 3. open the database in a new instance of Access and compact.
>
> 4. in the same instance (or a fresh one -- doesn't matter), compile
> (and in A97, COMPILE AND SAVE ALL).
>
> 5. compact again.
>
> Also, it's important that you always bypass any execution of code
> that would happen by default during the opening of your MDB,
> because if you decompile and then let the opening form open, that
> form has to be compiled and all of its dependencies compiled for it
> to open and youv'e just undone the decompiling, but only in a
> partial state!
>
> Keep in mind what decompiling does:
>
> It discards the compiled state of the code and leaves only the
> canonical, human-friendly code.
>
> But also keep in mind that the way storage works internally within
> an MDB, "discards" does not me "deletes from the file," it only
> means "marks the data pages where the compiled code is stored as
> deleted." This means:
>
> 1. your file remains fragmented, perhaps with inefficiently used
> data pages.
>
> 2. the compiled code is still in there, just no longer being used.
>
> So, for every step of the process, you need to do a compact to
> rewrite the file in the most efficient state, the defragmented
> state with all the deleted pages fully omitted.
>
> The other point: never use the instance of Access launched with the
> DECOMPILE switch for any other purpose, either compacting or
> compiling -- close it when the compile is complete and launch a
> fresh instance of Access.
>
> And, to stress Michael's point: decompiling may or may not make
> your file smaller, because you may have started from a state that
> was not fully compiled to begin with. The purpose of decompiling in
> *not* (and never was) to make a file smaller. It's purpose was to
> discard already compiled code and return the file to just the
> canonical code. That *may* have the benefit making the file smaller
> when it is one that has experienced lots of churn and has many,
> many pages of discarded compiled code still hanging around in
> unused data pages within the MDB.
>
> And one last point: the reason why A2K and later has no "COMPILE
> AND SAVE ALL" option is because everything in an A2K project is
> stored differently from A97 and before. In A97 and before, objects
> were stored one to a record in the tables used to store object
> definitions. In A2K and after, this was changed so that all objects
> are stored in a single record. Keeping in mind what you know about
> multi-user editing of regular Jet data, you'll realize that this
> means that you can't save a single field and not save other fields,
> so it also means that compiling always compiles *everything* in the
> database, all VBA code everywhere in the project. This was very
> plainly *not* the case in earlier versions of Access. That had both
> benefits and disadvantages, and MS decided to change it, with the
> result that we gain certain benefits and experience certain
> disadvantages as a result.
>
> One result is that there is that COMPILE means COMPILE ALL by
> definition, since there is no such thing as a COMPILE OPEN MODULES
> only, since the whole project is always open.
>
> --
> David W. Fenton http://www.bway.net/~dfenton
> dfenton at bway dot net http://www.bway.net/~dfassoc[/color]

[David W. Fenton]

Re: decompile in Access 2002?

t_NoSpam_redick @Mind_NoSpam_sp ring.com (TR) wrote in
<3F8B09BD.B5480 41F@Mind_NoSpam _spring.com>:
[color=blue]
>Certainly clear directions. I followed them explicitly, using a
>copy of the nwind.mdb. Disabled the startup form and custom menu,
>compacted, then proceeded. Grows incrementally with each
>iteration. Beginning size: 1980 kb
>1st iteration: 2096 kb
>2nd iteration: 2220 kb[/color]

What part of:
[color=blue]
> The purpose of decompiling in
> *not* (and never was) to make a file smaller.[/color]

is not clear?

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[TR]

Re: decompile in Access 2002?

I'm sorry, I missed the part about decompile will NOT make the smallest
possible database size.

Wait, perhaps I misunderstood this:
Actually /decompile WILL decrease size, when it is done correctly. (Michka)

Oh, and this:
then you will
see that for the smallest possible file, you must:
1) decompile the db
2) Compact it through the ACCESS, not DAO/JRO/Jet.
to get the SMALLEST possible db. (Michka again)


Just skipped over it. Somehow missed the part where database size will, not
just "possibly" increase, but consistently increase in size.

I've used decompile, judiciously, in Access 97. We utilize alot of activeX
controls, and develop on multiple OS's for distribution among multiple OS's.
I have found an occasional decompile to be extremely useful, under the right
conditions, in Access 97. However, I see this tip continued to be touted in
Access 2002. I work with Access every workday, I have yet to see ANY benefit
from decompile in Access 2002, even in situations where I felt that in
Access 97 it would have helped (try upgrading from comctl32 to mscomtl,
you'll love what decompile does in A97). Until I see some benefit, I cannot
believe that something has not changed in Access 2002 that totally renders
this "feature" useless. While the purpose may not be to reduce size, my
argument is that it INCREASES db size. Not fails to reduce. INCREASES.
CONSISTENLTY.



"David W. Fenton" <dXXXfenton@bwa y.net.invalid> wrote in message
news:9413ACB6Fd fentonbwaynetin vali@24.168.128 .90...[color=blue]
> t_NoSpam_redick @Mind_NoSpam_sp ring.com (TR) wrote in
> <3F8B09BD.B5480 41F@Mind_NoSpam _spring.com>:
>[color=green]
> >Certainly clear directions. I followed them explicitly, using a
> >copy of the nwind.mdb. Disabled the startup form and custom menu,
> >compacted, then proceeded. Grows incrementally with each
> >iteration. Beginning size: 1980 kb
> >1st iteration: 2096 kb
> >2nd iteration: 2220 kb[/color]
>
> What part of:
>[color=green]
> > The purpose of decompiling in
> > *not* (and never was) to make a file smaller.[/color]
>
> is not clear?
>
> --
> David W. Fenton http://www.bway.net/~dfenton
> dfenton at bway dot net http://www.bway.net/~dfassoc[/color]

[Wayne Gillespie]

Re: decompile in Access 2002?

On Tue, 14 Oct 2003 01:48:21 GMT, "TR" <trNO_SPAMedick @mindREMOVEspri ng.com> wrote:

FME the best way to reduce an A2002 mdn to it's smallest possible size, is to import all objects to a new clean mdb and then compact.
Even regularly compacting an A2K2 file (during development) will see a constant increase in file size.
A smaller file size was a side benefit of decompiling in A97, from what I have seen (as you have) decompiling in A2K2 increases the file size
progessively.

Importing to a clean mdb will usually see a huge reduction in file size. This is the last step I do before deploying an A2K/A2K2 database.

[color=blue]
>I'm sorry, I missed the part about decompile will NOT make the smallest
>possible database size.
>
>Wait, perhaps I misunderstood this:
>Actually /decompile WILL decrease size, when it is done correctly. (Michka)
>
>Oh, and this:
>then you will
>see that for the smallest possible file, you must:
>1) decompile the db
>2) Compact it through the ACCESS, not DAO/JRO/Jet.
>to get the SMALLEST possible db. (Michka again)
>
>
>Just skipped over it. Somehow missed the part where database size will, not
>just "possibly" increase, but consistently increase in size.
>
>I've used decompile, judiciously, in Access 97. We utilize alot of activeX
>controls, and develop on multiple OS's for distribution among multiple OS's.
>I have found an occasional decompile to be extremely useful, under the right
>conditions, in Access 97. However, I see this tip continued to be touted in
>Access 2002. I work with Access every workday, I have yet to see ANY benefit
>from decompile in Access 2002, even in situations where I felt that in
>Access 97 it would have helped (try upgrading from comctl32 to mscomtl,
>you'll love what decompile does in A97). Until I see some benefit, I cannot
>believe that something has not changed in Access 2002 that totally renders
>this "feature" useless. While the purpose may not be to reduce size, my
>argument is that it INCREASES db size. Not fails to reduce. INCREASES.
>CONSISTENLTY .
>
>
>
>"David W. Fenton" <dXXXfenton@bwa y.net.invalid> wrote in message
>news:9413ACB6F dfentonbwayneti nvali@24.168.12 8.90...[color=green]
>> t_NoSpam_redick @Mind_NoSpam_sp ring.com (TR) wrote in
>> <3F8B09BD.B5480 41F@Mind_NoSpam _spring.com>:
>>[color=darkred]
>> >Certainly clear directions. I followed them explicitly, using a
>> >copy of the nwind.mdb. Disabled the startup form and custom menu,
>> >compacted, then proceeded. Grows incrementally with each
>> >iteration. Beginning size: 1980 kb
>> >1st iteration: 2096 kb
>> >2nd iteration: 2220 kb[/color]
>>
>> What part of:
>>[color=darkred]
>> > The purpose of decompiling in
>> > *not* (and never was) to make a file smaller.[/color]
>>
>> is not clear?
>>
>> --
>> David W. Fenton http://www.bway.net/~dfenton
>> dfenton at bway dot net http://www.bway.net/~dfassoc[/color]
>[/color]

Wayne Gillespie
Gosford NSW Australia

[David W. Fenton]

Re: decompile in Access 2002?

trNO_SPAMedick@ mindREMOVEsprin g.com (TR) wrote in
<FBIib.48863$mQ 2.2459@newsread 1.news.atl.eart hlink.net>:
[color=blue]
>I'm sorry, I missed the part about decompile will NOT make the
>smallest possible database size.
>
>Wait, perhaps I misunderstood this:
>Actually /decompile WILL decrease size, when it is done correctly.
>(Michka)[/color]

Well, no, not necessarily. It depends on your starting point and
your ending point. The smallest possible file will be after a
decompile and a compact after the decompile, but *without* a
RECOMPILE. But that's not a very useful file, as it needs to be
compiled to run.

So, if you start from a fully compiled file and check the size,
then decompile, compact and recompile (and re-compact), you will
have a file that is, in most cases, the same size or smaller.

There are some exceptions to this, mostly, it seems in A2K files
that are new versus ones that have been used a bit. My first A2K
project was 8MBs when first converted from A97 and fully compiled.
But after use/programming, it would never compact below 14-15MBs or
so. Even importing everything into a fresh A2K MDB only reduced it
to 10-12MBs (I forget the exact size), and that would, with
programming and use, grow again to the size that would never
compact beyond 14-15MBs.

Access97 does *not* behave in this fashion, in my experience. You
can always decompile/compact to get back to nearly the original
size when it was a freshly imported MDB.
[color=blue]
>Oh, and this:
>then you will
>see that for the smallest possible file, you must:
>1) decompile the db
>2) Compact it through the ACCESS, not DAO/JRO/Jet.
>to get the SMALLEST possible db. (Michka again)[/color]

And he didn't say to recompile.
[color=blue]
>Just skipped over it. Somehow missed the part where database size
>will, not just "possibly" increase, but consistently increase in
>size.[/color]

If you then compile, of course the resulting file will be larger
than the decompiled/compacted version. But, of course, it *must*
be, as the compiled MDB has to store both the canonical code and
the compiled code, whereas the decompiled db had only the canonical
code, and is basically useless. You might ship of an MDB in that
format if you had a low-bandwidth client for home a few KBs of size
savings were significant.
[color=blue]
>I've used decompile, judiciously, in Access 97. . . .[/color]

I use it on a daily basis with A97, but only occasionally in A2K.
[color=blue]
> . . . We utilize alot of
>activeX controls, and develop on multiple OS's for distribution
>among multiple OS's. I have found an occasional decompile to be
>extremely useful, under the right conditions, in Access 97.[/color]

I find that with A97 it is an invaluable method for avoiding any
corruption whatsoever, and for keeping the project in good shape.
[color=blue]
>However, I see this tip continued to be touted in Access 2002. I
>work with Access every workday, I have yet to see ANY benefit from
>decompile in Access 2002, even in situations where I felt that in
>Access 97 it would have helped (try upgrading from comctl32 to
>mscomtl, you'll love what decompile does in A97). Until I see some
>benefit, I cannot believe that something has not changed in Access
>2002 that totally renders this "feature" useless. While the
>purpose may not be to reduce size, my argument is that it
>INCREASES db size. Not fails to reduce. INCREASES. CONSISTENLTY.[/color]

You still don't get it: the purpose of decompile is not to reduce
the size of an MDB. That is only a side effect (and only under the
right circumstances) of what decompile actually *does* do, which is
strip out the compiled code.

And the amount of size reduction will be proportional to the amount
of code and the degree to which code compiling (or constant
recompiling) is contributing to bloat of the MDB. In some cases,
that might be significant, but in most cases, it's trivial.

However, when you're doing heavy-duty development and doing lots of
coding and hitting the COMPILE button a lot (to test that your code
changes compile properly), you will see lots of bloat that is due
to discarded pages of compiled code. In those cases, DECOMPILE may
very well have a much more significant impact on file size than in
others.

I use DECOMPILE to make sure that the code in my projects stays
healthy. I use it much less in A2K than in A97 because it
accomplishes less towards that end because of the change in the
architecture of the way code is stored in an MDB. But I still use
it, nonetheless.

And in no cases do I worry at all about whether the resulting
recompiled MDB is smaller or not, as that is completely irrelevant.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[David W. Fenton]

Re: decompile in Access 2002?

bestfit@NObestf itsoftwareSPAM. com.au (Wayne Gillespie) wrote in
<t64nov4acbbti8 6288vsrv3eelcih polt2@4ax.com>:
[color=blue]
>Even regularly compacting an A2K2 file (during development) will
>see a constant increase in file size.[/color]

Is this A2K2 only, or applicable to A2K, too?

If the latter, I have to report that I've not seen it myself. My
A2K projects do not get larger with decompiling at all.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[bebelino]

Re: decompile in Access 2002?

On Mon, 13 Oct 2003 07:56:39 -0700, "Michael \(michka\) Kaplan [MS]"
<michkap@online .microsoft.com> wrote:

<CUT>

Thank you very much for the wonderful explanantion,
best regards,
--
bebelino

[bebelino]

Re: decompile in Access 2002?

On Mon, 13 Oct 2003 18:37:02 GMT, dXXXfenton@bway .net.invalid (David
W. Fenton) wrote:
[color=blue]
>
>Here's the proper decompile cycle:
>
>1. compact your database.
>
>2. decompile it and close the instance of Access used to decompile.
>
>3. open the database in a new instance of Access and compact.
>
>4. in the same instance (or a fresh one -- doesn't matter), compile
>(and in A97, COMPILE AND SAVE ALL).
>
>5. compact again.[/color]

Thanks for your reply and support,
best regards,
--
bebelino

[Wayne Gillespie]

Re: decompile in Access 2002?

On Tue, 14 Oct 2003 20:00:00 GMT, dXXXfenton@bway .net.invalid (David W. Fenton) wrote:
[color=blue]
>bestfit@NObest fitsoftwareSPAM .com.au (Wayne Gillespie) wrote in
><t64nov4acbbti 86288vsrv3eelci hpolt2@4ax.com> :
>[color=green]
>>Even regularly compacting an A2K2 file (during development) will
>>see a constant increase in file size.[/color]
>
>Is this A2K2 only, or applicable to A2K, too?
>
>If the latter, I have to report that I've not seen it myself. My
>A2K projects do not get larger with decompiling at all.[/color]

I have only noticed it in A2K2.

Wayne Gillespie
Gosford NSW Australia

[TR]

Re: decompile in Access 2002?

Hi David,
I get it. So, have you missed my point? Which is that decompile in A2K2
does not accomplish what it is supposed. I don't know about canonical text,
or orthodox text, 11 levels of compilation or 7 streams of consciousness.
But, in A2K2 decompile does not work. How does one tell whether it works or
not? Ok, I don't know. Ok, so you _may_ not see a size reduction. But surely
you would not see an increase, possible even substantial? And if you repeat
it, ever larger and larger file sizes? IMHO, something ain't working in A2K2
with decompile. Surely there would be a database somewhere that WOULD see a
reduction in size? I've tested on many, and have never seen it in A2K2.

I understand perfectly that reduction in size is not the purpose, and may or
may not result. But in A2K2 decompile INCREASES db size. I have NEVER seen
it decrease size. And this is both before, and after, recompiling after a
decompile. In fact from my observations, one of your comments could be
edited to "And the amount of size INCREASE will be proportional to the
amount of code and the degree to which code compiling (or constant
recompiling) is contributing to bloat of the MDB."

Starting with a large code heavy DB (57 mb compacted), decompile adds 6-8 MB
with every iteration (10-12 before compact/recompile).
A full import into a new DB will reduce my 57 MB file to about 27MB. Forget
that there was not a size reduction in decompile. Why do successive
iterations continue to ADD to the file size? What is decompile doing in A2K2
that is so different form prior versions?
While its intended purpose is NOT to reduce file size, yours and many
others comments indicate that size reduction is often a side benefit. IMHO,
in A2K2 this is simply not true. Decompile, what ever it does, will NOT
reduce bloat in A2K2. If anyone is concerned about bloat or
corrupted/discarded code, a full import into a new db is the best, and only,
recommendation I would make.
Do you have A2K2 to see this for yourself?


"David W. Fenton" <dXXXfenton@bwa y.net.invalid> wrote in message
news:9414AB4EDd fentonbwaynetin vali@24.168.128 .74...[color=blue]
> trNO_SPAMedick@ mindREMOVEsprin g.com (TR) wrote in
> <FBIib.48863$mQ 2.2459@newsread 1.news.atl.eart hlink.net>:
>[/color]
[color=blue]
>
> You still don't get it: the purpose of decompile is not to reduce
> the size of an MDB. That is only a side effect (and only under the
> right circumstances) of what decompile actually *does* do, which is
> strip out the compiled code.
>
> And the amount of size reduction will be proportional to the amount
> of code and the degree to which code compiling (or constant
> recompiling) is contributing to bloat of the MDB. In some cases,
> that might be significant, but in most cases, it's trivial.
>
> David W. Fenton http://www.bway.net/~dfenton
> dfenton at bway dot net http://www.bway.net/~dfassoc[/color]

[David W. Fenton]

Re: decompile in Access 2002?

trNO_SPAMedick@ mindREMOVEsprin g.com (TR) wrote in
<4Yajb.56840$mQ 2.10753@newsrea d1.news.atl.ear thlink.net>:
[color=blue]
>I get it. So, have you missed my point? Which is that decompile
>in A2K2 does not accomplish what it is supposed. . .[/color]

And you know this exactly how?

You might want to try the little experiment with constants that I
described in:

http://groups.google.com/groups?selm=9410A5569dfentonbwaynetinvali%4

024.168.128.74

(all on one line, naturally)

The point was this:

If you define one constant in terms of another, you need to do them
successively, though it may work if you compile between defining
successive constants.

The example was this:

Const c1 = 1

Then compile. Then before that declaration, add

Const c2 = c1 + 1

Compile and it will work.

Now, decompile, and then try to compile and again, and it won't
work.

The reason why it works the first time is that the c2 declaration
can be resolved because the module is already partially compiled,
with the value of c1 already written in as a literal in the
compiled code. Decompiling removes that precompilation so that it
won't compile because of the dependency of the one constant on the
definition of the other. If the constants are declared in order, so
that a dependent declaration comes *after* the declaration of the
constant it depends on, the code will compile.

But you could use this example as a way of testing if the compiled
code is, in fact, being discarded (though it's certainly not
definitive).
[color=blue]
> . . . I don't know
>about canonical text, or orthodox text, 11 levels of compilation
>or 7 streams of consciousness. But, in A2K2 decompile does not
>work. . . .[/color]

How do you know?
[color=blue]
> . . . How does one tell whether it works or not? Ok, I don't
> know.[/color]

Aha.
[color=blue]
>Ok, so you _may_ not see a size reduction. . . .[/color]

Reducing size is not the purpose for which decompile was created.

As has been repeatedly pointed out, size reduction could be a side
effect of decompiling.
[color=blue]
> . . . But surely you would
>not see an increase, possible even substantial? . . .[/color]

You are the one who admits to knowing nothing about it, yet insists
that it doesn't do what it is designed to do.
[color=blue]
> . . . And if you repeat
>it, ever larger and larger file sizes? IMHO, something ain't
>working in A2K2 with decompile. Surely there would be a database
>somewhere that WOULD see a reduction in size? I've tested on many,
>and have never seen it in A2K2.[/color]

Is the same problem present in A2K?
[color=blue]
>I understand perfectly that reduction in size is not the purpose,
>and may or may not result. But in A2K2 decompile INCREASES db
>size. . . .[/color]

In all cases, or in the case of the example you're using?

Does it matter if it's an A2K MDB or an A2K2 MDB?
[color=blue]
> . . . I have NEVER seen it decrease size. . . .[/color]

Have you tried it on numerous MDBs? On freshly created MDBs with
only a few lines of code? With nothing but modules in them?
[color=blue]
> . . . And this is both before,
>and after, recompiling after a decompile. In fact from my
>observations , one of your comments could be edited to "And the
>amount of size INCREASE will be proportional to the amount of code
>and the degree to which code compiling (or constant recompiling)
>is contributing to bloat of the MDB."[/color]

You are basically suggesting that there's a change of behavior
between A2K and A2K2, so far as I can tell. Break it down and
isolate it and then we can all perhaps figure out what's causing
the problem. My guess is that you're working with a corrupted MDB,
or that you're not working with A2K format.
[color=blue]
>Starting with a large code heavy DB (57 mb compacted), decompile
>adds 6-8 MB with every iteration (10-12 before compact/recompile).
>A full import into a new DB will reduce my 57 MB file to about
>27MB. Forget that there was not a size reduction in decompile. Why
>do successive iterations continue to ADD to the file size? . . .[/color]

This suggests corruption to me.

Keep in mind that if you import into a new MDB from a compiled MDB,
you may inherit all the corruption.

And in the case of a corrupted MDB that won't properly decompile
(there are certain circumstances where decompile always fails, such
as with certain kinds of conditional compiling), then all you've
found is a problem with corrupt MDBs, not a problem with decompile.
[color=blue]
> . . . What is
>decompile doing in A2K2 that is so different form prior versions?[/color]

I don't know -- you're the one who claims to know that decompile is
not doing what it's designed to do.
[color=blue]
> While its intended purpose is NOT to reduce file size, yours and
> many
>others comments indicate that size reduction is often a side
>benefit. . . .[/color]

Often, yes, because it does discard data pages. But it all depends
on what you're comparing, as I said in the message to which your
reply was a response.
[color=blue]
> . . . IMHO, in A2K2 this is simply not true. Decompile, what
>ever it does, will NOT reduce bloat in A2K2. . . .[/color]

Well, please, try to reduce it to a reproducible scenario. Create a
new MDB, and create one module in it with one subroutine. Then run
it through the decompile process (not leaving out any of the steps
and not using the decompile instance of Access for any other
purpose). If it still grows, then you've got a reproducible
scenario.
[color=blue]
> . . . If anyone is
>concerned about bloat or corrupted/discarded code, a full import
>into a new db is the best, and only, recommendation I would make.
>Do you have A2K2 to see this for yourself?[/color]

I don't have A2K2, no.

To track this down, I'd like to know if you're using A2K format or
A2K2 format. If A2K format, what happens when it is decompiled in
A2K instead of A2K2?

My suspicion is that your MDB is corrupted and that you're carrying
that corruption through all your imports. I've been there and done
that, and it can be a pain to detect.

The only real way to completely eliminate code corruption is to
export with SAVEASTEXT and then recreate your MDB with
LOADFROMTEXT.

If you do that and the MDB still grows with decompile, then, yes,
it seems that A2K has some problems.

But if you haven't eliminated the possibility of corruption, then
we don't know if the problem is with decompile or with your MDB.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[David W. Fenton]

Re: decompile in Access 2002?

bestfit@NObestf itsoftwareSPAM. com.au (Wayne Gillespie) wrote in
<f3voovs7uqckeh 8n1bjduf7t4id8f pb0i6@4ax.com>:
[color=blue]
>On Tue, 14 Oct 2003 20:00:00 GMT, dXXXfenton@bway .net.invalid
>(David W. Fenton) wrote:
>[color=green]
>>bestfit@NObes tfitsoftwareSPA M.com.au (Wayne Gillespie) wrote in
>><t64nov4acbbt i86288vsrv3eelc ihpolt2@4ax.com >:
>>[color=darkred]
>>>Even regularly compacting an A2K2 file (during development) will
>>>see a constant increase in file size.[/color]
>>
>>Is this A2K2 only, or applicable to A2K, too?
>>
>>If the latter, I have to report that I've not seen it myself. My
>>A2K projects do not get larger with decompiling at all.[/color]
>
>I have only noticed it in A2K2.[/color]

A2K format MDBs or A2K2?

If the former, does an A2K decompile remedy the problem?

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[Wayne Gillespie]

Re: decompile in Access 2002?

On Wed, 15 Oct 2003 15:15:18 GMT, dXXXfenton@bway .net.invalid (David W. Fenton) wrote:
[color=blue]
>bestfit@NObest fitsoftwareSPAM .com.au (Wayne Gillespie) wrote in
><f3voovs7uqcke h8n1bjduf7t4id8 fpb0i6@4ax.com> :
>[color=green]
>>On Tue, 14 Oct 2003 20:00:00 GMT, dXXXfenton@bway .net.invalid
>>(David W. Fenton) wrote:
>>[color=darkred]
>>>bestfit@NObe stfitsoftwareSP AM.com.au (Wayne Gillespie) wrote in
>>><t64nov4acbb ti86288vsrv3eel cihpolt2@4ax.co m>:
>>>
>>>>Even regularly compacting an A2K2 file (during development) will
>>>>see a constant increase in file size.
>>>
>>>Is this A2K2 only, or applicable to A2K, too?
>>>
>>>If the latter, I have to report that I've not seen it myself. My
>>>A2K projects do not get larger with decompiling at all.[/color]
>>
>>I have only noticed it in A2K2.[/color]
>
>A2K format MDBs or A2K2?
>
>If the former, does an A2K decompile remedy the problem?[/color]

I willt test it when I get a chance and report back.

Wayne Gillespie
Gosford NSW Australia