Error 2501 on DoCmd.Delete Form with Class Module and VBA View is Protected

[SolemnWishes]

Hi all,



My management has asked me to protect my program from theft. Unfortunately, my research has shown that if someone is intent on breaking through access, they will be able to. However, I can make it difficult enough that suck a hacker would be more than capable of writing a better program. This means our competitors (small business market) that have an incentive to steal it won't be able to because of a lack of programming understanding. Of course this is debatable, but whatever the case, I still need to show my management something.

That said, I wrote a code that will delete all objects (minus modules) in the database. I also password-protected VBA from viewing. Unfortunately, I run into a 2501 error when the code tries to delete forms with class modules, because the password does not allow any kind of edit on modules. My research suggests that I can't code a password-unlock-before and a password-lock-after the delete code.

I think the VBA program is more important than deleting some forms and modules, but I'd much prefer both. Anyone have any ideas?

Also, I'm thinking about running infinite loops on illegitimate copies.

Thank you all!

[rpeare]

How do you intend to trigger this module? If someone has made a copy of your database and renamed it and they have ten different names for the database (just for the sake of argument let's think of this as a competitor trying to reverse engineer your database) how do you intend to determine if the copy is legitimate or illegitimate? if it's an external file you install when you install a 'valid' copy couldn't your competitor just copy that file? If they hold down the SHIFT key when opening the database and this is an automatic 'validation' check (the code runs as soon as the database is opened) couldn't it be circumvented altogether?

I'm really curious how you intend to do this object deletion without potentially really screwing your real customers

You could potentially cycle through the system tables to scrub your database as well.

This must be a pain in the ass to test since, if successful, or even partially successful you have to make another copy of the database between each test.

[June7]

Publishing as an executable makes the VBA code unavailable.

[rpeare]

That too, though it does make updating the database a bit more troublesome

[ssanfu]

You could start by compiling the .accdb to a .accde (executable). See: http://www.databasedev.co.uk/convert...de_format.html
NOTE: Be sure to keep a current backup of the accdb. Preferably two backups.

The only other way I have heard/read about is to write the FE in VB6. Since it is compiled, there is no way to see the forms/code in design view.... you *must* have the source code.
The downside is that you must code for everything. Whereas Access does a lot of the heavy lifting for you, in VB you must create all objects. (takes more time)
Don't know about reporting in VB6.

[SolemnWishes]

Hi June7,

I never tire of your quick responses. As always, thanks!

I did a quick Google on the executable, but did not find much success. I'm wondering what the primary pros and cons are. Will my VBA codes work? How is the data saved? Can they access tables, queries, vba, or design view?

[June7]

If build in VB6 and want nice reports, think have to use another app add-in like Crystal Reports.

I've never published executable. It should run VBA code. It compiles the code so the raw code is not viewable. AFAIK, the VBA editor shouldn't even be available.

If you don't want Navigation Pane accessible, disable it with Database Options. Also disable function keys so F11 can't expand the Nav Pane. However, if the standard ribbon is available, can probably switch objects to Design view, however, I don't know if any edits can be saved.

Saving data is unchanged.

Experiment, won't hurt. The original file is not altered. In fact, have to use the original file for design edits and then republish the executable.