MDE and ACCDE files don't adequately protect your VBA source code.
Although compiled MDE and ACCDE files no longer contain the exact source code from the original file, they do contain a lot of extra compiler data that when combined with the compiled code, can be used to very accurately recover the original source code. EXAMPLE
If you want to improve the protection of your MDE and ACCDE files, then you need to remove this redundant compiler data. For this, you need Code Protector for Microsoft Access.
Analyses your application and displays the vulnerable parts of your code
Removes the vulnerabilities safely and securely (registered version only)
Afterwards, decompiling the source code produces far less desirable results
Supports Access files from v97 to v2013 (MDE, ADE and ACCDE file formats)
Includes support for Access 2010 & 2013 64-bit ACCDE file format
14 day money back guarantee
Only £49.99 (USD $80/EUR €60)
What is this extra compiler data?...
Normal MDE files contain extra detailed information that we like to call compiler junk - this is redundant information about variable names, data types, constants and UDTs that are no longer needed in a fully compiled MDE file.
This compiler junk makes it much easier to decompile and reverse-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.
The solution - Code Protector for Microsoft Access
If you want to properly protect your VBA code, then the solution is to remove the redundant compiler data from your MDE files completely which then makes it much harder and much less desirable for someone to decompile or reverse-engineer the source code.
Removing the compiler junk does not prevent decompiling or reverse-engineering the VBA code, but it does make it very much harder and the result would be source code that does not look anything like the original source code (and therefore much less understandable).
Example reverse engineered source code before and after protection
FAQ: Doesn't the /decompile switch do this?
No. The Access /decompile switch removes the compiled VBA code from an MDB file, ready for re-compiling. As soon as the VBA code is compiled again, the compiler junk exists again. Since all MDE files have to be compiled, the compiler junk is always present and makes it very easy to decompile your file (unless you use our Code Protector software).