Have you seen Error 49, Bad DLL calling convention, when running what appears to be your perfectly, well written code?
When this error occurs, it's usually after one of your procedures finishes and returns to its calling procedure. However, the message makes no sense because you haven't called a DLL. Debugging and stepping through your code drives you crazy because everything is working fine, yet the error keeps popping up.
It's driving you crazy and enough for you to throw away Access! What's going on?
Similarly, do your queries that have VBA code (such as Left, Mid, or UCase) start failing? How can something so simple all of a sudden stop working?
This can all be very confusing because it makes no sense. Everything looks fine. And Compact and Repair does not help.
The initial assumption is that the database is corrupt, which is partially true. People then resort to creating a new database and importing their objects into it which is time consuming and a pain. It solves the problem, but there's a much easier way.
Fortunately, there are a few options that can resolve this problem.
The first thing to check is whether the library references for your module code are valid. From the VBA IDE, go under Tools, References to see the list of referenced libraries and make sure none of the checked items say "Missing" in front of them. If so, fix that and your problem should go away. Assuming that's not the cause of the problem...
Unfortunately, over time, the part of your Microsoft Access database that stores VBA module code can become bloated, and in some cases, trigger strange errors such as Bad DLL calling convention.
As you compile and run code, VBA leaves behind old versions of the code that are no longer valid, but it is not always removed from the database. Database Compact and Repair only addresses the Jet tables in your database, and not the code. That's why it has no impact when this error arises.
Fortunately, Microsoft Access has a solution with the /decompile command line option.
When MS Access is started with this and you open a database, it discards all the old compilations and leaves just your VBA source code. You'll need to compile again to get the compiled state. After compacting, your database may be significantly smaller.
To decompile your database, follow these steps.
The database size should be reduced and the strange errors related to the VBA code should be gone.
To simplify doing this in the future (and you'll likely need this again), create a shortcut on your Windows desktop pointing to where your copy of Access is located:
C:\Program Files (x86)\Microsoft Office\root\Office16\MSACCESS.EXE /decompile
Then, whenever your database is acting oddly, you can easily launch the decompile version of Access to open your database and decompile it. In a few minutes, you're back up and running with a smaller database.
Total Visual Agent manages an unlimited number of databases across your network and schedule database chores in the middle of the night. Perform compact, backups, data extracts, running macros, command lines, and other tasks. Schedule events hourly, daily, weekly, monthly or just one time. Complete audit trail with email notification if anything goes wrong. Try the Free Trial today!
Total Access Admin lets you monitor Access databases in real-time to see who's currently in it and when they leave. It flags users who disconnect in a suspect manner which may indicate a source of database corruption. It can also perform tasks after everyone has exited such as compact. Try the Free Trial today!