Wrox Programmer Forums
| Search | Today's Posts | Mark Forums Read
Access Discussion of Microsoft Access database design and programming. See also the forums for Access ASP and Access VBA.
Welcome to the p2p.wrox.com Forums.

You are currently viewing the Access section of the Wrox Programmer to Programmer discussions. This is a community of software programmers and website developers including Wrox book authors and readers. New member registration was closed in 2019. New posts were shut off and the site was archived into this static format as of October 1, 2020. If you require technical support for a Wrox book please contact http://hub.wiley.com
  #1 (permalink)  
Old June 5th, 2005, 02:12 PM
Friend of Wrox
 
Join Date: Mar 2004
Location: Yorba Linda, California, USA.
Posts: 217
Thanks: 0
Thanked 1 Time in 1 Post
Default compile/decompile

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

  #2 (permalink)  
Old June 5th, 2005, 08:17 PM
Friend of Wrox
 
Join Date: Nov 2004
Location: Seattle, WA, .
Posts: 248
Thanks: 0
Thanked 1 Time in 1 Post
Default

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
  #3 (permalink)  
Old June 7th, 2005, 09:04 PM
Friend of Wrox
 
Join Date: Mar 2004
Location: Yorba Linda, California, USA.
Posts: 217
Thanks: 0
Thanked 1 Time in 1 Post
Default

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?

  #4 (permalink)  
Old June 8th, 2005, 09:01 AM
Friend of Wrox
 
Join Date: Nov 2004
Location: Seattle, WA, .
Posts: 248
Thanks: 0
Thanked 1 Time in 1 Post
Default

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.
  #5 (permalink)  
Old June 8th, 2005, 08:43 PM
Friend of Wrox
 
Join Date: Mar 2004
Location: Yorba Linda, California, USA.
Posts: 217
Thanks: 0
Thanked 1 Time in 1 Post
Default

Thanks! That makes more sense.



Similar Threads
Thread Thread Starter Forum Replies Last Post
C++......decompile an executable program danielnixon Visual C++ 1 August 6th, 2008 05:44 PM
Save Operation Failed error after decompile tunsted Access 0 October 31st, 2007 11:55 AM
compile aspb ASP.NET 2.0 Professional 1 September 12th, 2006 10:22 AM
Decompile Protection Eudora Servlets 0 July 18th, 2005 09:59 PM
C# compile biran Visual Studio 2005 1 July 15th, 2005 01:36 PM





Powered by vBulletin®
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.
Copyright (c) 2020 John Wiley & Sons, Inc.