Access Security Woes! (2000)

Topic

New Reply

In quite a few of my Access 97 databases I allow users to create their own modules but I do not allow them to mess up the ones that I created. I did this through securing the database, creating users and groups, and setting permissions.

Aparantly this kind module security is GONE in Access 2000. All the VBA code is secured by a singe password setup from the Project or VBA Editing window. So ALL the code is either secured or not. Does anyone know how I can accomplish what I did pretty easily in Access 97 in Access 2000? I think this is a step backward for Access. Was this change supposed to be for lazy people who want to secure there code without securing the database? Can someone explain to me how this is an improvement?

Thanks
James

Reply | Quote

Replies

I think that there are questions as to why users would or should be creating modules in an application??

If they are ‘power’ users creating modules for advanced functions on reporting, then perhaps you should be encouraging them to create modules in a reporting version of the database, rather than the ‘front-end’ application.

For users that create modules, what happens to their modules when you update the version of their database, their modules would be lost.

Another point is that most people distribute their applications as mde’s because they are compiled…which means that users can’t get in and change stuff in forms, modules etc AND Access runs an mde faster than and mdb so there are performance issues. Again this wouldn’t stop ‘power users’ wishing to report on the database from linking a seperate mdb that they ‘own’ and they could create modules until the cows come home.

Reply | Quote

Hello Jayden,

What you describe is exactly what I’m talking about. I distribute the main front end as an MDE. I also give them a “Report Writer” that is an Access MDB with links to the Back End data. I have a few modules and forms that allow the MDB to automatically re-link to the data on their hard drive (defauly location) or supply Open File dialogs to allow them to re-linlk to the data on their network. I’ve also designed several forms and code that allow users to easily share reports that they create. I create VBA patch files to update objects and code in the report writer without ever having to overwrite the entire MDB file. I want to secure my VBA in this report writer but still allow them to create VBA code if they want to.

Reply | Quote

There is another way to skin this cat. Create an Add-In or library database that has the Report Writer modules and forms in it, and then link it as a reference. You will need to make it an MDE so they can’t see or modify the code, and in it you will need to work with both databases. Doing this will require some extra effort on your part if you’ve not used this approach before, but we’ve had good success with it, and in fact the wizards and what not in Access are typically created this way.

FYI, this issue caused a major uprising when Access 2000 betas started showing up. Microsoft claimed it was neccessary in order to allow the used of a standard VBA set of tools across all Office applications, though some of use weren’t entirely convinced. Never the less, we have pretty much learned to work with it and it doesn’t seem such a big issue any more.

Reply | Quote

Thanks for the great idea. I’m not that experienced in creating my own ad-ins but I guess I’m going to have to learn. Where would you store the add-in on the end user machine? In the MS Office folder or in my Application’s folder?

Thanks again
James

Reply | Quote

There isn’t lots of documentation available from regular sources, but I believe the Access Developers Handbook has some stuff on it – also I think one of the WROX books does too, but I don’t remember which one. Also you might want to look at Q253338, and you might want to search this forum and the MS knowledge base on “addin” and “add in” – hope this helps.

Reply | Quote