From what I can gather you its either very difficult or impossible to decompile an MDE to edit VBA code.
It is possible and there are tools available to edit an MDE to view table information and create macros and new database objects. It is not possible (as far as I know) to edit existing forms, queries or VBA.

It is possible to reverse engineer the vba in an MDE file if you're familiar with machine code. There are also products available to do that for you. There are also products available that claim to make it very difficult to get useful VBA code from an MDE by removing information about the variables, function names, etc. Surprisingly, some vendors offer both :-)

It's going well, thanks :-). From the nature of this question, it sounds like your database is really moving along. Honestly, I have never tried these products myself so I can't vouch for them. I just know they are out there and am familiar with how they work at a very general level. A google search will bring up plenty.

>Is an MDE good enough...?
From my perspective, yes. Most of the db's I develop are organization-specific, and never make it to the MDE stage. We rely largely on trusted users and network security. It depends on the nature of your product, its users and deployment and what you stand to lose. In my case, the source code and database design are the among least of my worries.

well, it's going out to the masses and in anticipation of a killer app I am paranoid about the code. It's about as tight as one can reasonably expect. PDP and Jerryb30 helped me recently on this. One good link from PDB is http://www.aadconsulting.com/acdbmechanic.html).

From the site: "Worried that someone will reverse engineer your VBA code?... Make it less worthwhile for them by removing redundant "compiler junk" from MDE (or ADE) files using this easy to use utility"

A lot of security-related questions here seem to boil down to "How secure is my database?". The resounding answer is "it's not". In applying security measures, I believe the objective is to set up obstacles to make it difficult to compromise db security (that level of difficulty and effort varies depending on your needs). But if someone with adequate brains and determination really wants to crack the code...

Not trying to insult your code or anything ;-) but unless you've written something brand new and inventive in VBA terms, then all your code relates directly to making your particular application work well.
Which would only be of use to someone ripping off a direct copy of your application and going against it head to head no?
And that would be a HUGE step for any company to take. They'd be risking their entire business over saving themselves some development time.

Yes mde decompilers are becomming common - but I'd imagine the biggest users of them should be careless users who've lost the mdb, interested/nosey learners looking to see someone else's code, curious companies with existing competitor products checking to see they've not missed anything (with the last group being the least common - I may be giving human nature too much faith over business tactics, but that wouldn't be like me to do so!)

Code obfuscation is a feature included in our Total Visual CodeTools product. It lets you rename all your constants, variables, and private procedures to a letter and number. It strips out all the comments, blank lines, blank spaces, etc. It doesn't prevent someone from reverse engineering an MDE, but it does make the results less useful. FWIW, .NET suffers from similar problems.

Total Visual CodeTools also offers a variety of other coding utilities in order of my favorites:

1. Line numbering so your error handler can pinpoint exactly what line of code a crash occurs

Supposedly (I have never used it), you can set it up so that your program installs to an encrypted container (e.g. directory) and the container works on the osmosis principle (licensees can get in the container in unencrypted fashion.......but anything coming out of the container (e.g. a copy of program) is encrypted.

sorry, I fell asleep while the discussion was in full gear ! Thanks to all for the comments.

EE is like computer games (which I don't play). New doors keep being opened and inside is a whole new world . . .

Main point I learned in the last week is that it is possible to re-engineer MDE code; I thought the whole point was that the code is stripped out so how could one get the code? Live and learn. Anyway . . .

Miriam, I have built in lots of obstacles so I think it's about as protected as possible (except for maybe the MDE protector)

LPurvis, I agree with your points. Yes, the code is not ground-breaking :-( but I just have a mindset of protecting the code (and my investment) as much as possible, so was inquiring about the MDE re-engineering situation. At the moment, $130 for the MDE protector is not worth it . . . I guess I'm a somewhat of a neophyte, it's still odd that the point of an MDE is to strip out the code (for security I assume) yet it can be re-built. I figured stripping out the code meant it was a .exe of sorts (all binary) that was not readable at all. But pretty much with computers, if someone can break it, they will, corporate or otherwise. It's pretty much like EE, in the negative way.

Luke, I like the tool, it looks awesome ! But my risk management cut-off point (budget) doesn't require getting the tool, but it looks awesome. Also, the fact that .Net suffers from the same risk is interesting . . .

PDB, yes I did look at this when you posted - that was a long time ago! (so sorry for the semi-repeat). I even tried it out and can't remember for sure but it created some pretty big size barrier that I wasn't willing to wrestle with. But I like what it says "Impossible to break" - THAT'S what I'm looking for (but still not necessary at this point).

From a computer perspective, the challenge is that at a root level, the computer needs the instructions to run it's processes, so it's always possible to reverse engineer machine code. That's not limited to Access, .NET, or Windows.

The primary purpose of MDE's is to make it difficult for users to modify the code in it. It doesn't prevent users from modifying other parts of it like tables, queries, macros, etc. Programs such as Excel don't even have an MDE feature, so its code is always exposed. We know people who use Total Visual CodeTools to obfuscate their Excel VBA code.

Sorry to hear your organization doesn't have the budget to buy additional tools. Hopefully, over time you'll find professional solutions from organizations like FMS to be helpful for increasing your productivity. If you're starting, I would recommend you look at our Total Visual SourceBook product with its royalty-free source code and Total Access Analyzer which will help you diagnose your work for opportunities to apply best practices, increase performance, and fix errors before you ship. See www.fmsinc.com for more info.

thanks for the follow up, very helpful. As far as the budget, I'm working in the garage at night . . . and corporate during the day :-)

About re-engineering the code, I guess my perspective was a mainframe, which I worked on a while ago, not extensively. What I remember is - if you lose the source code (on a mainframe) - you're toast. Get another job . . .

Featured Post

Like “For Dummies” books, you can read this in whatever order you choose and learn about mobility and BYOD; and how to put a competitive mobile infrastructure in place. Developed for SMBs and large enterprises alike, you will find helpful use cases, planning, and implementation.

This article describes two methods for creating a combo box that can be used to add new items to the row source -- one for simple lookup tables, and one for a more complex row source where the new item needs data for several fields.

Add bar graphs to Access queries using Unicode block characters. Graphs appear on every record in the color you want. Give life to numbers.
Hopes this gives you ideas on visualizing your data in new ways ~
Create a calculated field in a query:
…

Visualize your data even better in Access queries. Given a date and a value, this lesson shows how to compare that value with the previous value, calculate the difference, and display a circle if the value is the same, an up triangle if it increased…