Decompile from VBA?

Question

I know it can be done use vbscript or a batch file (/decompile), but is there anyway to decompile a database by simply using VBA?

I am trying to build a procedure to decompile/recompile/compact and repair.

Also, the decompile command, should it be issued on the development pc or on the computer used to run the database?

Answer 1

First of all, while there are some very possible downsides to de-compile, they are so rare that of in 13 years of reading and posting an online forms, I cannot find one poster or anyone who has ever had a problem as a result of de-compile. 

On the other hand I can in fact find hundreds if not 1000 of posts mentioning the benefits and positive outcomes of doing a de-compile.

In other words you might reach some article on the Internet of someone who burn their hands because they were changing the oil in a car. Wile burning your hand during changing the oil your car is some kind of caution you want to respect, none would conclude from such information that that's a bad idea to change the oil in your car.  In other words it's a good idea to use de-compile, and it's a good idea to change the oil in your car – they both have risks and caution must be exercised, but is still great advice at the end of the day.

So it's important to note, that you can NOT execute a de-compile inside of the application you are running since you running code! The code you would be running needs to be removed and that is not realistically possible when you're running that code.

A rather simple solution here is to simply set up a shortcut on your desktop to the ms access.exe.  You then edit the command line to add the /decomple to what the shortcut created, you then simply copy the shortcut into your send two folder, and at this point you'll have a right click send to option that allow you to de-compile any database.

I also suggest that when you do the de-compile you will hold down the shift key during startup, else you now have code that run and that means code has now been compiled. If you sending the database to someone else, then you do NOT want to have had any code run since then you had code compile on YOUR machine.

And, right after that de-compile, you will find that doing a compact and repair reduces the size of the file (it should be about the smallest size it can get, since all code and extra stuff will be removed after a compact and repair).  As noted, you hold down the shift key and not let any startup code run for this compact and repair just like you did for the decompile.

In fact, I think the benefits of the de-compile are so positive, it should probably be an option in the menu system (and that idea has been considerd).  In I just experienced my first rounds of instability with access 2010 with the recent SP1 update (as a side note, I've had very good luck and very good stability with 2010). The FIRST set of issues and problems cropped up with SP1 and doing a de-compile on those 2010 applications has returned everything to rock solid stability.

OK, so now that we put this issue into perspective, and realize the great benefits of de-compile, we can now move onto your next issue in question.

The next issue here, is why you having frequent problems with this particular application.  The most common result of such freezes suggests that more than one user opening and using the application at the same time. 

Unfortunately you're going to find out that access is not very reliable when you do this.  So if this is a network based application in which several users are opening it at the same time, you want to ensure that you have a split database, and that you deploy a copy of the application to each WorkStation.  And preferably you'll find that if you distribute an mde , or accDE, then once again the application tends to remain in a compiled state and tends to run better.

Albert D. Kallal  (Access MVP)

Edmonton, Alberta Canada

Answer 2

Certainly you can write code to do a decompile on a different database than the one you're running the code from. Basically it would be the same code as the equivalent VBScript.

As to where you should decompile, the issue is where you should RECOMPILE. You should always recompile in an instance of Access that is as close as possible to the version in production use, or that is maximally forward-compatible. That would mean you'd use the oldest version of Access in production use. That can still cause problems in some cases, though.

Answer 3

Thank you for the link.  The information was educative.

I am not looking to use this all the time, but am having weird issues with a previously working db since the move the server to have runtime 2002 and Office 2007, but my dev PC is using Office 2003.  So I thought I'd decompile and recompile of the server in the hopes that this remedies these issues.  Am I wrong?

Answer 4

While a little dated, see MichKa's explanation about what decompiling does at http://www.trigeminal.com/usenet/usenet004.asp

Answer 5

Have you tried using the Shell command?

Shell "C:\Program Files\Microsoft Office\OFFICE12\MSACCESS.EXE  C:\YourDatabase.mdb /decompile"

The Office folder depends on which version of Office you have installed.