After doing a lot of vba work, I've noticed the size of my mdb has grown,
even though no data or objects have been added.
I've read that the following procedure will remedy this and improve
performance:
1. From the command line, type msaccess.exe /decompile.
2. Open the database you want to decompile.
3. Open up any module. Select the Compile All Modules and Save All Modules
menu items.
4. Compact and repair the database
5. Close the database and close Access.
The first problem I'm having is with step 3 -- I can find "compile" under
the debug menu, but I don't see anything that says "compile all modules" or
"save all modules".
The other problem is that after I do this, the size of the mdb is LARGER
than when I started!
Is there a different procedure for Access 2002?
Other suggestions for decompiling?
28  6527 
Hello,
'Compile' compiles all modules. 'Save' saves all what there is to be saved.
So no need to look for 'Compile All'-Button. Maybe make step 3b (between 3
and 4: Close the DB)
Then after decompile the DB is bigger, after the compile even more. The
final compact and repair should bring it to the minimal size.
That's how it works with Acc 2000, if decompile does not bring the same
result with Acc 2002 please let me know ;-)
regards
Alex
"deko" <dj****@hotmail.com> schrieb im Newsbeitrag
news:8d*********************@newssvr21.news.prodig y.com... After doing a lot of vba work, I've noticed the size of my mdb has grown,
even though no data or objects have been added.
I've read that the following procedure will remedy this and improve
performance:
1. From the command line, type msaccess.exe /decompile.
2. Open the database you want to decompile.
3. Open up any module. Select the Compile All Modules and Save All
Modules menu items.
4. Compact and repair the database
5. Close the database and close Access.
The first problem I'm having is with step 3 -- I can find "compile" under
the debug menu, but I don't see anything that says "compile all modules"
or "save all modules".
The other problem is that after I do this, the size of the mdb is LARGER
than when I started!
Is there a different procedure for Access 2002?
Other suggestions for decompiling?
I tried it a few different times on the same AC2002 database and each time
the results were the same: it was bigger than before I decompiled it.
"Al Wendl" <al**@wasc.ch> wrote in message
news:3f**********@news.tiscalinet.ch... Hello,
'Compile' compiles all modules. 'Save' saves all what there is to be
saved. So no need to look for 'Compile All'-Button. Maybe make step 3b (between 3
and 4: Close the DB)
Then after decompile the DB is bigger, after the compile even more. The
final compact and repair should bring it to the minimal size.
That's how it works with Acc 2000, if decompile does not bring the same
result with Acc 2002 please let me know ;-)
regards
Alex
"deko" <dj****@hotmail.com> schrieb im Newsbeitrag
news:8d*********************@newssvr21.news.prodig y.com... After doing a lot of vba work, I've noticed the size of my mdb has
grown, even though no data or objects have been added.
I've read that the following procedure will remedy this and improve
performance:
1. From the command line, type msaccess.exe /decompile.
2. Open the database you want to decompile.
3. Open up any module. Select the Compile All Modules and Save All
Modules menu items.
4. Compact and repair the database
5. Close the database and close Access.
The first problem I'm having is with step 3 -- I can find "compile"
under the debug menu, but I don't see anything that says "compile all modules"
or "save all modules".
The other problem is that after I do this, the size of the mdb is LARGER
than when I started!
Is there a different procedure for Access 2002?
Other suggestions for decompiling?
On Wed, 08 Oct 2003 21:41:38 GMT, "deko" <dj****@hotmail.com> wrote: I tried it a few different times on the same AC2002 database and each time
the results were the same: it was bigger than before I decompiled it.
Yes, but have you done what Al Wendl told you? I've recently
decompiled a few of my databases myself and it all worked well.
After compiling and saving all modules (just press the savebutton-
don't look for save all modules, it's very important to save them they
say), you have to close the database & access. When you have marked in
the options 'compact on close', I think it's better to turn it off
before you start with the whole process of deompile.
Okay, after closing database and access you start access again
normally and open up your database. Then you do a compact and repair.
Close access again and go looking for the size of your DB. Now it
should be shrinked.
regards,
--
bebelino
okay, I tried it again. I turned off the "compact on close" option, and
configured the database not to load any form on open (it just cmes up tothe
database window).
Here's what I did step by step:
1. created shortcut:
"C:\Program Files\Microsoft Office\Office10\MSACCESS.EXE" "C:\Documents and
Settings\Administrator\Desktop\MyDatabase.mdb" /decompile
2. launched shortcut
3. opened a module in the database and selected "compile" from the Debug
menu
4. selected File >> Save MyDatabase (from the menu bar in the VB window)
5. closed the database
6. opened the database
7. selected Tools >> Database Utilities >> Compact and Repair Database (from
the menu bar in Access)
8. closed the database
9. repeated steps 6 through 8
Result -- Database is BIGGER than before...
hmmm....... the only thing I can think of is that I have Office Developer
installed -- might that screw something up??
"bebelino" <a.*@c.d> wrote in message
news:1d********************************@4ax.com... On Wed, 08 Oct 2003 21:41:38 GMT, "deko" <dj****@hotmail.com> wrote:
I tried it a few different times on the same AC2002 database and each
timethe results were the same: it was bigger than before I decompiled it.
Yes, but have you done what Al Wendl told you? I've recently
decompiled a few of my databases myself and it all worked well.
After compiling and saving all modules (just press the savebutton-
don't look for save all modules, it's very important to save them they
say), you have to close the database & access. When you have marked in
the options 'compact on close', I think it's better to turn it off
before you start with the whole process of deompile.
Okay, after closing database and access you start access again
normally and open up your database. Then you do a compact and repair.
Close access again and go looking for the size of your DB. Now it
should be shrinked.
regards,
--
bebelino
On Thu, 09 Oct 2003 11:15:16 GMT, "deko" <dj****@hotmail.com> wrote: okay, I tried it again. I turned off the "compact on close" option, and
configured the database not to load any form on open (it just cmes up tothe
database window).
Is the compiling of your database running properly? I mean, doensn't
it stop to point you at errors in code?
Sorry, don't know any further solution to your problem.
Success!!
regards,
--
bebelino
Perhaps the database is encrypted.
--
MichKa [MS]
This posting is provided "AS IS" with
no warranties, and confers no rights.
"bebelino" <a.*@c.d> wrote in message
news:g2********************************@4ax.com... On Thu, 09 Oct 2003 11:15:16 GMT, "deko" <dj****@hotmail.com> wrote:
okay, I tried it again. I turned off the "compact on close" option, and
configured the database not to load any form on open (it just cmes up
tothedatabase window).
Is the compiling of your database running properly? I mean, doensn't
it stop to point you at errors in code?
Sorry, don't know any further solution to your problem.
Success!!
regards,
--
bebelino
Success!! The mdb reduced in size by 57% and performance improved.
1. Create a blank database (configured not to load any form on startup, and
with compact on close deselected).
2. Reboot the computer.
3. Import all objects from production database.
4. Restart Access with the /decompile option while holding down the Shift
key.
5. Close access after database window is displayed.
6. Open the database while holding down the shift key.
7. Open a module and select "Compile" from the Debug menu.
8. Compact and repair the database.
9. Close the database.
"bebelino" <a.*@c.d> wrote in message
news:g2********************************@4ax.com... On Thu, 09 Oct 2003 11:15:16 GMT, "deko" <dj****@hotmail.com> wrote:
okay, I tried it again. I turned off the "compact on close" option, and
configured the database not to load any form on open (it just cmes up
tothedatabase window).
Is the compiling of your database running properly? I mean, doensn't
it stop to point you at errors in code?
Sorry, don't know any further solution to your problem.
Success!!
regards,
--
bebelino
Hi Deko,
I have found what you described in original post to be the case in Access 2002.
Decompile procedure increases db size. Even see this with copy of NWind.mdb, so
its not my code/db that is the issue (plus have tried on several different dbs,
all the same result).
Your solution, while effective, is is not the result of decompile. Importing all
objects, without the decompile step, is what caused your size reduction. You
would see similar size reduction without decompile. I have used a full import to
reduce db size, but we have some large complex secured applications, and
security settings are not imported. They must be recreated manually (or scripted
with code).
I wrote to the editors of Advisor magazine about this. They recently wrote the
decompilation up as a tip to reduce db size. I still say this does not work in
Access 2002.
TR
deko wrote: Success!! The mdb reduced in size by 57% and performance improved.
1. Create a blank database (configured not to load any form on startup, and
with compact on close deselected).
2. Reboot the computer.
3. Import all objects from production database.
4. Restart Access with the /decompile option while holding down the Shift
key.
5. Close access after database window is displayed.
6. Open the database while holding down the shift key.
7. Open a module and select "Compile" from the Debug menu.
8. Compact and repair the database.
9. Close the database.
"bebelino" <a.*@c.d> wrote in message
news:g2********************************@4ax.com... On Thu, 09 Oct 2003 11:15:16 GMT, "deko" <dj****@hotmail.com> wrote:
okay, I tried it again. I turned off the "compact on close" option, and
configured the database not to load any form on open (it just cmes up tothedatabase window).
Is the compiling of your database running properly? I mean, doensn't
it stop to point you at errors in code?
Sorry, don't know any further solution to your problem.
Success!!
regards,
--
bebelino
well, then I'm not crazy after all.... erk abk ind et unm...
thanks for the comment...
"TR" <t_NoSpam_redick@Mind_NoSpam_spring.com> wrote in message
news:3F87208A.3A0630A9@Mind_NoSpam_spring.com... Hi Deko,
I have found what you described in original post to be the case in Access
2002. Decompile procedure increases db size. Even see this with copy of
NWind.mdb, so its not my code/db that is the issue (plus have tried on several different
dbs, all the same result).
Your solution, while effective, is is not the result of decompile.
Importing all objects, without the decompile step, is what caused your size reduction.
You would see similar size reduction without decompile. I have used a full
import to reduce db size, but we have some large complex secured applications, and
security settings are not imported. They must be recreated manually (or
scripted with code).
I wrote to the editors of Advisor magazine about this. They recently
wrote the decompilation up as a tip to reduce db size. I still say this does not
work in Access 2002.
TR
deko wrote:
Success!! The mdb reduced in size by 57% and performance improved.
1. Create a blank database (configured not to load any form on startup,
and with compact on close deselected).
2. Reboot the computer.
3. Import all objects from production database.
4. Restart Access with the /decompile option while holding down the
Shift key.
5. Close access after database window is displayed.
6. Open the database while holding down the shift key.
7. Open a module and select "Compile" from the Debug menu.
8. Compact and repair the database.
9. Close the database.
"bebelino" <a.*@c.d> wrote in message
news:g2********************************@4ax.com... On Thu, 09 Oct 2003 11:15:16 GMT, "deko" <dj****@hotmail.com> wrote:
>okay, I tried it again. I turned off the "compact on close" option,
and >configured the database not to load any form on open (it just cmes up
tothe >database window).
Is the compiling of your database running properly? I mean, doensn't
it stop to point you at errors in code?
Sorry, don't know any further solution to your problem.
Success!!
regards,
--
bebelino
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.
I guess if you want to call being mistaken a definition for "crazy" then
that is your prerogative. But if you ask me I would say that you are
mistaken again, in that case? :-)
--
MichKa [MS]
This posting is provided "AS IS" with
no warranties, and confers no rights.
"deko" <dj****@hotmail.com> wrote in message
news:dt*************@newssvr27.news.prodigy.com... well, then I'm not crazy after all.... erk abk ind et unm...
thanks for the comment...
"TR" <t_NoSpam_redick@Mind_NoSpam_spring.com> wrote in message
news:3F87208A.3A0630A9@Mind_NoSpam_spring.com... Hi Deko,
I have found what you described in original post to be the case in
Access 2002. Decompile procedure increases db size. Even see this with copy of NWind.mdb, so its not my code/db that is the issue (plus have tried on several
different dbs, all the same result).
Your solution, while effective, is is not the result of decompile. Importing all objects, without the decompile step, is what caused your size reduction.
You would see similar size reduction without decompile. I have used a full
import to reduce db size, but we have some large complex secured applications, and
security settings are not imported. They must be recreated manually (or
scripted with code).
I wrote to the editors of Advisor magazine about this. They recently
wrote the decompilation up as a tip to reduce db size. I still say this does not
work in Access 2002.
TR
deko wrote:
Success!! The mdb reduced in size by 57% and performance improved.
1. Create a blank database (configured not to load any form on
startup, and with compact on close deselected).
2. Reboot the computer.
3. Import all objects from production database.
4. Restart Access with the /decompile option while holding down the Shift key.
5. Close access after database window is displayed.
6. Open the database while holding down the shift key.
7. Open a module and select "Compile" from the Debug menu.
8. Compact and repair the database.
9. Close the database.
"bebelino" <a.*@c.d> wrote in message
news:g2********************************@4ax.com...
> On Thu, 09 Oct 2003 11:15:16 GMT, "deko" <dj****@hotmail.com> wrote:
>
> >okay, I tried it again. I turned off the "compact on close"
option, and > >configured the database not to load any form on open (it just cmes
up tothe
> >database window).
>
> Is the compiling of your database running properly? I mean, doensn't
> it stop to point you at errors in code?
> Sorry, don't know any further solution to your problem.
> Success!!
> regards,
> --
> bebelino
On Sun, 12 Oct 2003 10:39:54 -0700, "Michael \(michka\) Kaplan [MS]"
<mi*****@online.microsoft.com> wrote: 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.
Well then, could you please tell what the right steps are?
--
bebelino
"bebelino" <a.*@c.d> wrote... Well then, could you please tell what the right steps are?
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.
a.*@c.d (bebelino) wrote in
<gp********************************@4ax.com>: On Sun, 12 Oct 2003 10:39:54 -0700, "Michael \(michka\) Kaplan
[MS]"
<mi*****@online.microsoft.com> wrote:
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.
Well then, could you please tell what the right steps are?
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
David W. Fenton previously wrote: 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.
So a compile always 'compiles all' but it is possible for <sections> of
code to become decompiled?
I find this odd but I'm not techie enough to fathom it.
Regards
Peter Russell
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: "bebelino" <a.*@c.d> wrote...
Well then, could you please tell what the right steps are?
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.
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: a.*@c.d (bebelino) wrote in
<gp********************************@4ax.com>:
On Sun, 12 Oct 2003 10:39:54 -0700, "Michael \(michka\) Kaplan
[MS]"
<mi*****@online.microsoft.com> wrote:
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.
Well then, could you please tell what the right steps are?
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 t_NoSpam_redick@Mind_NoSpam_spring.com (TR) wrote in
<3F8B09BD.B548041F@Mind_NoSpam_spring.com>: 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
What part of:
The purpose of decompiling in
*not* (and never was) to make a file smaller.
is not clear?
--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
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" <dX********@bway.net.invalid> wrote in message
news:94***************************@24.168.128.90.. . t_NoSpam_redick@Mind_NoSpam_spring.com (TR) wrote in
<3F8B09BD.B548041F@Mind_NoSpam_spring.com>:
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
What part of:
The purpose of decompiling in
*not* (and never was) to make a file smaller.
is not clear?
--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
On Tue, 14 Oct 2003 01:48:21 GMT, "TR" <tr************@mindREMOVEspring.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. 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" <dX********@bway.net.invalid> wrote in message
news:94***************************@24.168.128.90. .. t_NoSpam_redick@Mind_NoSpam_spring.com (TR) wrote in
<3F8B09BD.B548041F@Mind_NoSpam_spring.com>:
>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
What part of:
> The purpose of decompiling in
> *not* (and never was) to make a file smaller.
is not clear?
--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Wayne Gillespie
Gosford NSW Australia tr************@mindREMOVEspring.com (TR) wrote in
<FB******************@newsread1.news.atl.earthlink .net>: 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)
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.
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)
And he didn't say to recompile.
Just skipped over it. Somehow missed the part where database size
will, not just "possibly" increase, but consistently increase in
size.
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.
I've used decompile, judiciously, in Access 97. . . .
I use it on a daily basis with A97, but only occasionally in A2K.
. . . 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.
I find that with A97 it is an invaluable method for avoiding any
corruption whatsoever, and for keeping the project in good shape.
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.
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 be*****@NObestfitsoftwareSPAM.com.au (Wayne Gillespie) wrote in
<t6********************************@4ax.com>: 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.
--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
On Mon, 13 Oct 2003 07:56:39 -0700, "Michael \(michka\) Kaplan [MS]"
<mi*****@online.microsoft.com> wrote:
<CUT>
Thank you very much for the wonderful explanantion,
best regards,
--
bebelino
On Mon, 13 Oct 2003 18:37:02 GMT, dX********@bway.net.invalid (David
W. Fenton) wrote:
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.
Thanks for your reply and support,
best regards,
--
bebelino
On Tue, 14 Oct 2003 20:00:00 GMT, dX********@bway.net.invalid (David W. Fenton) wrote: be*****@NObestfitsoftwareSPAM.com.au (Wayne Gillespie) wrote in
<t6********************************@4ax.com>:
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.
I have only noticed it in A2K2.
Wayne Gillespie
Gosford NSW Australia
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" <dX********@bway.net.invalid> wrote in message
news:94***************************@24.168.128.74.. . tr************@mindREMOVEspring.com (TR) wrote in
<FB******************@newsread1.news.atl.earthlink .net>:
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 tr************@mindREMOVEspring.com (TR) wrote in
<4Y*******************@newsread1.news.atl.earthlin k.net>: I get it. So, have you missed my point? Which is that decompile
in A2K2 does not accomplish what it is supposed. . .
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...waynetinvali%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).
. . . 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 do you know?
. . . How does one tell whether it works or not? Ok, I don't
know.
Aha.
Ok, so you _may_ not see a size reduction. . . .
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.
. . . But surely you would
not see an increase, possible even substantial? . . .
You are the one who admits to knowing nothing about it, yet insists
that it doesn't do what it is designed to do.
. . . 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.
Is the same problem present in A2K?
I understand perfectly that reduction in size is not the purpose,
and may or may not result. But in A2K2 decompile INCREASES db
size. . . .
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?
. . . I have NEVER seen it decrease size. . . .
Have you tried it on numerous MDBs? On freshly created MDBs with
only a few lines of code? With nothing but modules in them?
. . . 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."
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.
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? . . .
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.
. . . What is
decompile doing in A2K2 that is so different form prior versions?
I don't know -- you're the one who claims to know that decompile is
not doing what it's designed to do.
While its intended purpose is NOT to reduce file size, yours and
many
others comments indicate that size reduction is often a side
benefit. . . .
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.
. . . IMHO, in A2K2 this is simply not true. Decompile, what
ever it does, will NOT reduce bloat in A2K2. . . .
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.
. . . 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?
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 be*****@NObestfitsoftwareSPAM.com.au (Wayne Gillespie) wrote in
<f3********************************@4ax.com>: On Tue, 14 Oct 2003 20:00:00 GMT, dX********@bway.net.invalid
(David W. Fenton) wrote:
be*****@NObestfitsoftwareSPAM.com.au (Wayne Gillespie) wrote in
<t6********************************@4ax.com>:
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.
I have only noticed it in A2K2.
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
On Wed, 15 Oct 2003 15:15:18 GMT, dX********@bway.net.invalid (David W. Fenton) wrote: be*****@NObestfitsoftwareSPAM.com.au (Wayne Gillespie) wrote in
<f3********************************@4ax.com>:
On Tue, 14 Oct 2003 20:00:00 GMT, dX********@bway.net.invalid
(David W. Fenton) wrote:
be*****@NObestfitsoftwareSPAM.com.au (Wayne Gillespie) wrote in
<t6********************************@4ax.com>:
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.
I have only noticed it in A2K2.
A2K format MDBs or A2K2?
If the former, does an A2K decompile remedy the problem?
I willt test it when I get a chance and report back.
Wayne Gillespie
Gosford NSW Australia This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Rene Blom |
last post by:
Hello,
i am trying several times to get my access '97 D-base in a access 2002
D-base but every time I get a mention that the D-bade is closed en wil be
repared.
Help please
|
by: Scott |
last post by:
Hi,
If we want to compile an Access 2002 database and distribute it to
others, will the compiled software run on any PC, like Windows 98,
Windows 2000, etc.
Also, you don't have to have...
|
by: Wayne Aprato |
last post by:
I have several Access 2003 mde databases. When I try to open them in
Access 2002 I get the following error:
"The Visual Basic for Applications project in the database is
corrupt."
...
|
by: Esmee |
last post by:
Hi there,
Hope you guys can help me out.
For one of my clients I have created an Access 2002 db. It used to be
under Access97, but I have converted it to Access 2002, without any
problems.
My...
|
by: Rob |
last post by:
Scenario:
O/S: Win XP Professional
Back-end: Access 2002 on network server
I have an Access 97 application, in production on our network, that
takes appoximately 5 minutes to process monthly...
|
by: Steve Jorgensen |
last post by:
I'm working on an application in Access 2002, and every time I'm done making
changes in the VBA project, the database is noticeably larger after
compacting, even when code changes are small or even...
|
by: Frav |
last post by:
The Reps team have been experiencing that Access 2002 unexpectedly
quits
while working and also lots of Corruption Failures and "Record lock
can not
update" messages since the upgrade from...
|
by: Bugs |
last post by:
Hi everyone.
I am trying to open a database which works fine using Access 2003, but when
trying to open it on another PC that has Access 2002 I get the following
error
"This database is...
|
by: Sebastian |
last post by:
Hello
I develop my applications in Access 2002. My development system is
running Windows XP SP2 and I have Microsoft Office XP Developer.
Microsoft Office XP is at SP3.
I used Inno Setup (great...
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome a new...
|
by: conductexam |
last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and...
| |
