How do I protect my code from being seen? 1

[EarS]

I have an app that is going to be distributed to users shortly. I have used the microsoft access security wizard to secure all my forms queries ect... but should my program ever error it always brings up the option to debug it, thus leaving my code visible. We have written a lot of custom code for this system. Is there anyway besides putting on error handlers in every event to prevent the users from seeing it?

Thanks in Advance,

Matt

 

[snoopy75]

I believe if you make an .mde file, then Access stores only the assembly language code for your modules, or something like that. The point is, it's no longer accessible, even by you. So be sure to make a backup of the .mdb file before doing this.

You make an .mde file under Tools -> Database Utilities, I believe.

--Ryan

 

[DaOtH]

Setting a password to the VB code solves this issue.

If in this case an error occurs the user won't get the option to debug the code. "In three words I can sum up everything I've learned about life: it goes on."
- Robert Frost 1874-1963

 

[EarS]

How do you set a password in Access???

 

[snoopy75]

That's under the menu Tools -> Security, I believe.

 

[DaOtH]

If you mean a password for your VBA code, then go to the VBA editor (Tools -> Macro)

In the VBA Editor, go to Tools -> Properties and see the Protection Tab.

Debug option won't be offered then anymore to y'r users.
"In three words I can sum up everything I've learned about life: it goes on."
- Robert Frost 1874-1963

 

[Steveje]

I would simply make an mde file as outlined above. When you make an mde file it does not destroy your mdb. It creates the mde as a sepparate file that you can them place where you want the users to access it from. When doing any operations like this it is always a good idea to make a back up anyway incase something goes awry.

 

[VogonPoet]

The mde file is definitely the most direct method to achieve you end result. However, this is one possible gotcha - Does your code open/edit any reports/forms in design mode? If so, the mde solution won't work - or you'll need to rewrite some of you code.

Michael

 

[Laois]

An MDE file is the best solution, but you must have error handling otherwise if the user gets an error, your application will crash. You should have error handling regardless of how you distribute the database. If you are using Access 2000 it has a wizard that can add basic error handling to the complete application in one go. At least this will stop it from crashing.

Dermot

 

[abysas]

You can use a database property "AllowBreakIntoCode" to specify whether or not the user can view Visual Basic code after a run-time error occurs in a module. But the best solutions is the MDE file.

 

[danvlas]

"but should my program ever error it always brings up the option to debug it"

That means your code is flawed by lack of error trapping.

As a program developer, you must think of all possible errors that may occur in each line of code and trap them all in an error handling piece of code that should exist in any procedure, be it Sub or Function.

On Error Resume Next

is the statement to be used when ALL errors that may appear are insignificant and their skipping does not affect anything. For instance, the attempt to append a duplicate record will fail because of the primary key. The above statement will skip the offending line and move to the next statement. This is only an example, depending on the specific cases, such error may need handling.

In all other cases, you need something like:

On Error GoTo ErrHandler
'all your code here

Cleanup:
Set rst = Nothing
Exit Sub 'or Function

ErrHandler:
Select Case Err.Number
Case 3020
MsgBox "To update the recordset you have to use Edit or AddNew"
Resume Cleanup
'Other cases here
Case Else 'this is for impossible cases
MsgBox Err.Description
Resume Cleanup
End Sub

It just has to be done (in my opinion )

And after that, convert the database to an mde file...


Daniel Vlas
Systems Consultant
danvlas@yahoo.com

 

[RottPaws]

I concur with what has been said above about error handling and making an mde.

With that said, if you just want to stop users from seeing code after an error occurs, Access 97 has an option called 'Allow Viewing Code After Error' on the Advanced tab of Tools/Startup... Just uncheck this option.


For Access 2000, you'll have to do as DaOTH instructed above.
_________
Rott Paws

...It's not a bug. It's an undocumented feature!!!

 

[bjd4jc]

Lets say you go with the MDE approach. What happens if, in the future, you would like to make a few modifications to the database. If you store your code and your data in the mde file, then when you go to upgrade, how do you get the data out of the MDE file? Or, would you just use an MDE file and an MDB file?

 

[danvlas]

Keep a copy of the originating mdb file in a safe place.

Daniel Vlas
Systems Consultant
danvlas@yahoo.com

 

[RottPaws]

If you go with the MDE option (and it's a good practice even if you don't), you should actually have 2 databases. One is the back-end that has tables and contains the data. The other is the front in that has forms, queries, etc, but doesn't actually store the data. Instead, the front end has linked tables to the back end.

When you have multiple users on a network, you can put the back-end database on a common network drive and link the front end to the tables in it. Then distribute a copy of the front-end to each user. The front-end copies will run from each user's own PC and access the shared data on the network drive.

I also like to keep a copy of the back end to use for testing/devolpement. When changes need to me made to the app, they can be made to the mdb copy of the front-end after pointing it to the test copy of the back end so you can test adding/deleting/modifying data.

Once all changes have been made, point the front-end back to the live back-end database, make your new mde file and distribute it out to the users . . . _________
Rott Paws

...It's not a bug. It's an undocumented feature!!!