When things go wrong, the first thing that I typically do is watch the data, which will typically give clues as to the nature of the problem. Most frequently, problems with database applications are related to logic issues, code issues, or poorly designed queries. Although solving these problems can be complex, it's a fairly straightforward process. You trace code, you monitor data, and you eventually arrive at a solution.

However, sometimes the logic is sound, the code is fine, but things still don't work. When everything seems fine but still doesn't work, start to suspect that the internal code of Access is flawed. This happens periodically, and is one of the reasons that Microsoft will release service packs for its applications. A good place to start with a problem is to make sure you have the most recent service pack. (See this month's tip for more information on service packs.)

In other cases, you will find that you have the most recent service pack and everything is still not working properly. When you reach this point, it's time to try a decompile.

When you write code in Visual Basic for applications (VBA), you are writing in something close to English; VBA however is not executed by your computer. There is an intermediary step of taking your code and turning it into machine code that the computer understands and can execute very quickly.

The process of going from your English-like code to the code that the machine reads, is called compiling. This happens transparently and is something in which you have no involvement. Once a chunk of code has been compiled, it does not get compiled again (recompiled) unless the code changes.

Every once in a while the compiled code becomes damaged. Although there is probably a reason for this, to me it has always been something of a black box to why this happens. To fix this type of issue, you must decompile the code and then recompile it.

Decompile is essentially saying to Access: all the code in the program must be compiled again. This process will untangle any machine code that has become damaged.

To decompile your code, you must start access with a parameter, in this case /decompile.

To do this, though, is just a tad tricky because you must start Access and give it the decompile parameter when you start it, not after. Most all of us start Access by clicking on an icon or starting a file that has an MDB extension. To provide a parameter to Access you have to give the full path to the program, and then follow it by the decompile statement.

So in my case, since my access application is in the program directory, I have to give the following command:

"C:\Program Files\Office2K\Office\MSACCESS.EXE" /decompile
all one lone

In this case, the quote marks are essential because there is a space between the word program and the word files. Without the quotes, the statement will not run.

Execute this from the run command. Find the run command by clicking on the start menu and choosing run. The exact placement of the run command will vary between operating systems, but you should be able to find it by looking in the start menu.

Once you run the decompile command, Access will start as it normally does and invite you to choose a database to open. Whatever database you pick will be decompiled, so make sure that you choose the program that has been giving you problems. When the program opens, Access will decompile the code, then the next time the code is called, it will recompile.

At this point, I recommend that you actually go to the code window and choose debug, then choose compile. By doing this, any syntax errors will be apparent immediately.

This will solve most of your problems that are not logic or syntax based. Occasionally, this won't approach won't fix the things and you will have to import the objects in your application into a fresh program. For help doing that, take a look at the February 2008 Access Wizard where I give details on how to make this happen.