Pardon my ignorance, but could someone explain "decompile".

I've seen a number of forum members use the term, and I've seen it used in a few other sources related to using Access/VBA. The context appears to be they are "compiling" their code in their project.
It is my understanding that in VB (and other development languages/environments), one COMPILES a project (source code changed into code that can be read by the machine, making the file into an executable file). Yet in Access, when one turns VBA code into P-code, (but not creating an executable) it appears people are calling the process "decompile"? (In English "De-compile" hints it is an opposite to "compile").

Did I miss something? I'm really confused- could someone set me straight please?

Thank you,
Loralee

I wouldn't call it ignorance. I worked without decompiling for 4 or 5 years before I learned about it. And if I'd have known about it sooner, I might not have gotten so frustrated.

Access doesn't truly do a compile in the sense that most people think of it unless you create an MDE or ADE. However, for efficiency (better performance), Access will take your code and do a sort of compile. Ultimately, your computer doesn't know what "If X=Y then" really means. So the VBA code must be turned into something machine readable at some point.

Also note that there is an option in the VBE (Visual Basic Editor) under the Debug menu to compile your code. Have you ever deleted or renamed a procedure in a BAS module that is used in a form somewhere? Did you get a syntax error when you deleted/renamed it? No. But if you do the compile, you find out.

I don't know all of the details. But when the code is saved, Access will assume that that code is all that will ever run. But when you go into VBE, and start changing code, Access knows it has to throw out whatever it thought was going to be the code and reinterpret that code for efficiency.

Where things get a little screwy is when you are running a form (not in Design Mode) and change the code. Then Access is trying to catch up with what you're doing. Also, if you rename objects (forms, reports, etc) Access has data that keeps track of those renames. At any rate, sometimes Access just loses track -- it has its improved performance code that it thinks is up-to-date when in fact it is not. The best way to get Access to catch up again is start Access with the /decompile parameter. Then it knows it has to throw out the old interpretations and start over.

It never hurts to /decompile. In fact, some "professional" developers will use it just before they are ready to put their code to a full test. You will know you need to /decompile when you know the code should be working but it doesn't. That gets a little tricky. A clear example is when you change the text of a message box (MsgBox) and the message displays the old text. (I have actually seen this!) In other situations, you have to be really, really sure it isn't a bug in your code that makes it seem that your code isn't executing.

I know that doesn't give you the full technical explanation behind this. But that is the essence of what is happening. Hope it helps.

Randall J Weers
Membership Vice President
Pacific NorthWest Access Developers Group
http://www.pnwadg.org

So essentially, it is the same thing? "/decompile" from Start>run is same as choosing "compile" from the menu in the Access environment???? And BOTH are doing roughly what VB is doing when going through a "compile" (eventhough they appear to sound like opposites?

I'm sorry. I was affraid I messed that up.

/decompile does do what you think it linguistically should do. Well, more or less. It removes previous compile information. Linguistically one would think that it actually takes a compiled object and reverts it to the form it was prior to a compile. But decompile doesn't turn machine code into source code - it just throws away old machine code.

Let's try it this way. Access starts compiling when you run a form or report or anything that accesses code or when you select Debug | Compile in the VBE. Starting Access with the /decompile parameter and then opening a database will remove all of the previous compile information from that database. This forces Access to ignore any previous compile information about that database.

If you start Access with /decompile and don't let any code run at startup when you open a database and immediately close that database, that database will NOT have compile information for Access to use the next time the database is opened.

If you open a form or report or use anything that runs code or select the Compile option in VBE, Access will start to accumulate compile information for that database whether or not you started Access with the /decompile parameter.

The thing is, since Access needs that compile information to run forms or report, etc., the /decompile is only a temporary thing. It is so temporary, it seems to me that there should be a menu option in VBE to allow you to "start over". Alternatively, when you select Compile in VBE, there should be an option to say, "remove previous compile information and start from scratch". That should be the default since many databases don't have so much code that it would take all that long to compile the whole database.

Ultimately, VBA is not Access and vice versa. VBA is a more-or-less standalone app that Access uses. I don't know if Excel or Word keep compile information the way Access does. But perhaps the VBE doesn't have the Decompile/Recompile from scratch option because Access isn't the only application that uses it.

Thanks! That makes more sense.