how do I change module security levels in access?

[Guest]

On a database with its own mdw, I join the workgroup, go to
tools/security/user and group permissions and under "object type" MODULES
doesn't show up. How can I give ADMIN read design rights so I can import
them into another database using the standard system.mdw workgroup?

 

[Chris Mills]

Since Access2000, "modules" or VBA code is not separate to each form or object
like it used to be in A97. Instead, all code is now "stuffed into one thing"
as-it-were, which is separately protected by a code password (any vba code,
Tools, YourMDB Properties, Protection)

That's how code is now protected (except for mde's where source is stripped
out). Whether or not the code password is more or less protected than other
password mechanisms like the separate User Level Security passwords, is a good
question. Nevertheless, code protection has little to do with ULS from A2000
onwards.

I believe you are thinking in Access97 terms. It all changed in this matter.

As to how you give rights to import code to a new owner, I've forgotten and
would appreciate someone jumping in to help here. I suspect that somewhere you
might have to give the code password?
Chris

 

[Guest]

Thanks, Chris, but let me give a bit more info.

I got this application from a vendor who wrote it for another state agency
here in Texas, and are making the code available, but there is very little
documentation. I did, however, get the dbowner username and password used in
the mdw file. It was done in A97, and I'm on A2002. I'm trying to move all
the tables and forms/reports into a plain old A2002 mdb with no workgroup so
I can make some changes. First, I had to convert the mdw and mdb files
(front end in one mdb and back end in another) to A2002 before I could make
any changes to the security.

hr.mdb has tables, queries...modules, and there's a hrdev.mdw workgroup
file. I "joined" the workgroup (I never really liked this terminology) and
opened hr.mdb, and went to tools/security/user and group permissions. I
selected the user Admin, select object type tables, select all tables, and
add all permissions. I did the same thing for queries, forms, reports, and
macros, but there is no listing for modules. OK, according to your note
(appreciated), these are all stored differently than in A97. I opened the
"project" in the vb editor, and go to tools/properties/protection, and the
project is not locked for viewing, and no password that I can see.

I'm using the standard workgroup: C:\Documents and
Settings\woodland_bc\Application Data\Microsoft\Access\System.mdw

I open newhr.mdb, then click on file/get external data/import, and point to
hr.mdb. In the "Import Objects" dialog box, it lists tables,
queries...modules. I click modules tab, then select all, then import. This
is what I get:

You don't have permission to import, export, or link to 'basActsExport.'
To import, export, or link to this object, you must have Read Design and
Read Data permissions for it. For more information on permissions and who
can set them, click Help.

How the heck am I supposed to give Admin read rights to the modules in A2002?

 

[Chris Mills]

I'm not sure if this is the best or only way, but can you logon to the
original db as the original owner and export the modules.

Chris

 

[TC]

IMHO it would be easier for you if you descured it in A97 first. Google
this group for desecure a database, there should be lots of hits.
/Then/ convert it to A2k.

Note: you say you want to convert it into an A2k mdb "with no workgroup
[file]". Access /always/ uses a workgroup file. It is impossible to run
it without one. If you're not clear about this, try the Access Security
FAQ, often referenced in this newsgroup.

HTH,
TC

 

[Guest]

The module security settings are still there, but not
exposed in the security wizard (you need to use code).
The module security settings control the behaviour
of Access, but not VBA: if a module is secured, you
can't load it by double-clicking in the Access window,
but you can open the VBA window and then open
the module.

(david)