Summary of the problem with normal MDE files created by Microsoft® Access:
Normal MDE files created by Access contain extra information that we like to call "compiler junk" - this is redundant information about variable names, data types, constants, UDTs etc that are no longer needed in a fully compiled MDE file.
However, this "compiler junk" makes it much easier to decompileeverse-engineer the VBA code in an MDE file to a standard that is very close to the original VBA source code (including for example all variable names).
In fact, for those that can prove ownership of their MDE files, we at EverythingAccess.com offer a service for reverse-engineering them including all VBA code. You must be able to prove lawful ownership beyond any doubt for our service - but that is not to say that another company (or utility) won't offer a non-validated conversion service in the future.
But I thought that the VBA source code in MDE files had been stripped out?
Yes, you're quite correct. However, the source code can be re-built with very high accuracy by using the combination of the compiled code and the "compiler junk" which is left behind by Access when creating the MDE file.
So what's the solution?
Well, if you want to better protect your VBA code, then the solution is to remove the extra "compiler junk" from the MDE file completely which makes it much harder and much less desirable to decompileeverse-engineer the source code. By removing the "compiler junk" does not prevent decompilingeverse-engineering the VBA code, but it does make it that much harder and the result would be source code that does not look anything like the original source code (and therefore much less understandable).