So I have been able to secure a database so you have to log into it to get access to the data. Only big problem right now is that I can access all the posts. There is by that a potential risk of none experienced Access users ruining the data for someone else by deleting such a post. How can I solve this issue as smooth as posible?
Questions on locked databases
- Thread starter jobro
- Start date
Len Boorman
Back in gainfull employme
- Local time
- Today, 20:06
- Joined
- Mar 23, 2000
- Messages
- 1,927
Also do not give then Edit or Delete within the database.
View only. BUT not at network permission level. Needs to be controlled inside the database
L
View only. BUT not at network permission level. Needs to be controlled inside the database
L
Len Boorman
Back in gainfull employme
- Local time
- Today, 20:06
- Joined
- Mar 23, 2000
- Messages
- 1,927
If you are worried about them deleting then you can take away the Delete, that's okay
You do also need to consider that Edit facility can effectively screw records as well. Like delete you will perhaps never know a record has gone until you specifically look for it.
An incorrect edit, How will you know.
What I am saying is that you need to assess your users carefully and
Any delete routine should ask for at least a confirmation of delete before it happens and should only be available to a few users
Edit can also be a problem so limit this to a few users
Leaves you with View only for a bunch of users, If they spot something that needs deleting or editing they contact another user with those capabilities who first checks out the request.
If the data is really valuable then you do have to really look after it and only allow "Senior" users to edit and delete.
The process I generally use is to have Core Users. These Users are defined for each application. They basically take the role of Administrator and can do everything because they are generally the people who have asked for the application and therefore take responsibility for the application and users.
Nobody can view the database window and that includes Core Users, Nobody can put anything into design view. F11 key disabled, By Pass key disabled.
If then a Core user cannot do something then they have to come to me because I always have a way in to the database window etc.
Len
You do also need to consider that Edit facility can effectively screw records as well. Like delete you will perhaps never know a record has gone until you specifically look for it.
An incorrect edit, How will you know.
What I am saying is that you need to assess your users carefully and
Any delete routine should ask for at least a confirmation of delete before it happens and should only be available to a few users
Edit can also be a problem so limit this to a few users
Leaves you with View only for a bunch of users, If they spot something that needs deleting or editing they contact another user with those capabilities who first checks out the request.
If the data is really valuable then you do have to really look after it and only allow "Senior" users to edit and delete.
The process I generally use is to have Core Users. These Users are defined for each application. They basically take the role of Administrator and can do everything because they are generally the people who have asked for the application and therefore take responsibility for the application and users.
Nobody can view the database window and that includes Core Users, Nobody can put anything into design view. F11 key disabled, By Pass key disabled.
If then a Core user cannot do something then they have to come to me because I always have a way in to the database window etc.
Len
