Decompile/Recompile

[Guest]

After finally repairing my database corruption, as advised I decompiled and
then recompiled, and compacted. Now I have more questions.

I've come across some instructions for decompiling a database and they all
seem kind of complicated to me. I searched in Access help and under the
section "Improve Visual Basic code performance" the first item says that
renaming a database decompiles the code. Well then, I can do that. Why
then, are there these other multi-step instructions out there?

For example:

http://www.granite.ab.ca/access/decompile.htm

Second question: Once I've decompiled, recompiled, and compacted is doing
this on the .mdb good enough for all the FE's out there or do I have to
update all the FEs. I've tested one FE on a different computer and it seems
to be running fine.

Nicole

 

[Arvin Meyer [MVP]]

Nicole,

Sometimes renaming an Access 95 project will fix a corruption problem. I've
never heard of it changing anything later. I just checked and neither
renaming the database file, nor the project decompiles Access 2000 through
2003. Check it yourself. Do it on a compiled copy and see if it decompiles
anything.

The best information on decompiling is available on Michael Kaplan's
website, a link to which you can get through here:

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

Second answer: Fixing 1 file only files that file, nothing else. I suggest
that you put it on the server and use it to replace any other ones on your
network. Sometimes easier to fix corruption, I simply create a new database
and import everything. Corruption, which is often in embedded deleted
garbage is left behind. I then the startup properties, and references, and
compile the new file.

 

[David W. Fenton]

I've come across some instructions for decompiling a database and
they all seem kind of complicated to me. I searched in Access
help and under the section "Improve Visual Basic code performance"
the first item says that renaming a database decompiles the code.
Well then, I can do that. Why then, are there these other
multi-step instructions out there?

For example:

http://www.granite.ab.ca/access/decompile.htm

You're confusing two senses of the term "decompile."

When you hit the compile button in Access 2000 and up, it compiles
the whole project (or in A97 and before, if you do COMPILE AND SAVE
ALL). At that point the whole project is said to be "compiled." If
you type one character in any module, the project will be
"decompiled" because there's one line of code that is uncompiled.

This is *very* different from what the /decompile switch does. The
decompile switch completely discards all compiled p-code and keeps
only the canonical VBA code that you typed. The Michael Kaplan
article that Arvin referred you to explains this in more detail.

The point is:

The /decompile switch cleans out *everything* in terms of the
compiled code and returns your project to the pristine state before
even one line has been compiled. The difference is that your
instance of decompiling ends up with one line of code decompiled,
while the /decompile switch leaves you not one single line that is
compiled.

 

[Tony Toews [MVP]]

If
you type one character in any module, the project will be
"decompiled" because there's one line of code that is uncompiled.

I'd call that "no longer compiled" or "uncompiled".

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/

 

[Arvin Meyer [MVP]]

The /decompile switch cleans out *everything* in terms of the
compiled code and returns your project to the pristine state before
even one line has been compiled. The difference is that your
instance of decompiling ends up with one line of code decompiled,
while the /decompile switch leaves you not one single line that is
compiled.

More accurately, it opens everything to be cleaned upon a compact.

One sees an additional, sometimes drastic, size difference after a compact
once the database has been decompiled. This is especially true if the
project has been worked on for some time.

 

[Jon Ament]

There are, or were, bugs in the way decompile worked with
object./class definitions, which could trash your project if it
included object/class definitions other than standard forms
and reports.

There were, or are, problems with the way compact and
decompile interacted, which could prevent recovery of unused
space in the VBA project.


In all current versions of Access, the VBA project is no longer
stored in a relational database by a relational database system.
Instead, it stored in a binary blob, so it can not be accessed
or manipulated by the relational database system. In particular,
it can't be compacted, referential integrity cannot be applied,
and multi-user support is not available.

In access 95, the VBA project was stored in a relational
database by a relational database system, and the project
name was the root key to the compiled project records.
Changing the project name detached the compiled project.
records. That no longer applies.


If you are using a split database system, there is normally
no reason to decompile the BE. It doesn't have anything inside
the Project blob anyway.

If you compact the BE, you may have to compact or relink
the FE. Compacting the BE will re-organise the tables if you
have added or deleted fields in the table design, which may
invalidate linked tables.

(david)

 

[rudi]