How to debug a compiled access database (accde)

Question

I have an access front-end that connects to SQL Server tables and works fine. When I compile it into an accde file however, I get various errors when closing the DB. The errors seem to indicate that the program is still looking for a table or the value of a global variable. There is a routine in the Form_Close() event of a hidden form that Deletes all the links to the SQL Server back-end. So, how can I debug an already compiled access database? Why does the compiled DB behave differently than the uncompiled (accdb) version?

Answer 1

You need to trap errors using On error goto LabelName or if you don't care about errors you should use On error resume next on top of your code. You should still post your code to get more accurate help.

Answer 2

Are you talking about the same computer, or different computer?

The compiled accDE are VERY sensitive to being executed on a different machine (even the same version). The reason for this is that the compiled accDE takes on your current office release version. In terms of global variables, and error handling? accDE's are the BEST choice, since un-handled errors does not re-set local, or even global variables. In effect, a accDE runs like a un-stoppable freight train.

if your accDB (un-compiled) works and runs fine on your computer, then I have NEVER seen a case in which the accDE does not run, and in fact run better and behavies far more ro-bust.

So, no, you can't debug the accDE, but you can the accDB on the SAME computer.

If you are running the accDE on a different computer, then you left out a massive, huge and SPECTUALAR bit of information in your post.

If you ARE running the accDE on the same computer (that you created it with), then about the only possible is that the accDE file extension is using a different version of access to run with. This is rare - I would thus from the control panel, applications and features find your version of access and right click and do a repair on your office install.

The issue of patch version of office/access is VERY significant here. The reason of course is that if you deploy the accDB, it will often work because access can (and does) detect that the current version (even SP/patch/update) level of Access is different, then it can re-compile the code on the fly (because the accDB has the source code). The accDE does not, and thus it can't re-compile. However, I still STRONG suggest you deploy the accDE and resolve the SP/patch level issue since a accDE is oh so much more reliable in its operations compared to un-compiled accDB's.

I would be rather stunned if you are experiencing this issue on the same computer running the accDB and that computer is then used to create the accDE. If this is the actual case, then I would create a new blank accDB, and import everything from the old accDB, and then ensure it can compile the code (from IDE debug->compile). If the app compiles, then create the accDE, and it should work just fine. So, if this is same machine, then your accDB is damaged or corrupted. As I stated, create a new one, import everything from old, and create your accDE from that. It will work, and I never seen a case in which a accDB works, and a accDE does not work (on same machine).

Answer 3

1st thing to do is to decompile your application ...just Google Ms Access Decompile. When you perform the Decompile and try to compile is almost certain that you will find some "forgotten" mistakes.
2nd if 1st fails its time to implement a robust logging system...based on text file writing, in order to avoid dependencies just work low : https://learn.microsoft.com/en-us/office/vba/language/reference/user-interface-help/freefile-function.
If it still fails post back with more info.