MSAccess security problems

[jessnyc]

hi, i just started using access and i created a simple database of clients for my office by making a table. the table had information imported into it from another program. in any case, because our 5 or 6 computers are on a network, i wanted to create some kind of security so that only 2 of us had full access to editing and updating info, so i used the security wizard to set up users and passwords. i did nothing else before that, like workgroup administrator. when i went to open up the database it doesn't let me and says that there are no read definitions and not even the backup copy it created opens up, it says something about permissions. Please help!! what do i do, where did i go wrong, how can i fix it? i set up the database from my computer and from that same computer, that security thing as well. i printed out the paper with the personal id's it gives for the users i set up, but i don't know how that would help. Please!!! I need to have it fixed before anyone at work finds out!!

[NooNoo]

Welcome to Windrivers jessnyc

Well first off, you may have to come clean about this - it's an error, and assuming you were messing with this stuff as part of your job, then there is no problem.

Did you remove yourself from the Admins Group?
Can your users view the data? (login as a user you created)

[jessnyc]

I created the database and my coworkers are not too comfortable using it, they think they will accidently erase something, so my boss asked if there was any way to secure it so that data couldn't be erased, and that's where it all started.
well, i've been looking for help everywhere on the access help menu and i think i got this far in understanding the problem:

I had never run workgroup administrator when i ran the user-level security wizard, and secondly, when i ran the wizard, i did not prompt it to use the default file that was created when access was first installed. After the wizard a backup copy was made, which opened for the first few times and then gave me a permissions error.

Does this mean i have to rebuild the workgroup information file? This is all new to me.

Please help!

[jessnyc]

what should also be noted is that only one computer in the office actually has access installed on it (not mine), so we put a shortcut to the program on the network drive.

oh, and no, no one else can open the database.

the thing is, it doesn't prompt anyone to put in a password, it doesn't do anything.

[confus-ed]

So you did this or very similar ?

In which case I think the answer to this; Does this mean i have to rebuild the workgroup information file? .. is most probably yes.

I've never done it this way though, I always managed it 'enough' by using permissions in NTFS & by setting 'exclusive mode' to stop two folks at once changing things.

Can I ask how these 'nervous' users actually use the database ? I'm confus-ed by "they think they will accidently erase something" - are they meant to be able to change anything or just be able to see the stuff ?

[NooNoo]

If you don't want them changing or deleting stuff, then only provide them with views of the data. Use queries and forms to create views.

[confus-ed]

If you don't want them changing or deleting stuff, then only provide them with views of the data. Use queries and forms to create views.

That sounds like a remarkably simple side step , *if* they are only meant to view things, but its also kind of why I asked

[El_Squid]

Access security has always been squirrely and we use the users' login IDs from their machines and our own coded security levels in the tables themselves. Another good step is to have the "front end", i.e. the forms and reports MDE, on the users' machines and link them to the tables, kept in an MDB on a shared network folder. This also allows you to control security with network rights, i.e. read/write/execute, as -ed suggested. You are entitled to distribute a runtime version of access to your users in the setup/distribution wizard, and by giving them an MDE, you can keep nosy users from being able to edit forms, reports and modules. Finally, be sure to backup and compact those tables regularly.