Question Protecting data (1 Viewer)

pottsr09

New member
Local time
Today, 03:37
Joined
May 19, 2017
Messages
4
Hello Everyone!

I am building a database for myself and a couple of co-workers so we can keep track of issues at work. The issue I am having is I want to know if I can make it where if one of us enters data that the others cannot edit it, but the original person that entered the data can. Is this possible to do in MS Access 2010?

Thanks!

Ryan
 

CJ_London

Super Moderator
Staff member
Local time
Today, 08:37
Joined
Feb 19, 2013
Messages
16,553
yes it is possible.

a) you need to use a form for data entry, not directly into a table or query
b) you need a basis for logging in (consider the environ function)
c) each record in the table needs to be populated with the user ID of the person who created the record

Once you have that done, the rest is down you how your app works, for example

d) you might filter the recordsource to your form to only show records that user created
e) or if you want other users to see the data, but not edit it, you can use conditional formatting to disable the appropriate controls (for a single or continuous form)
f) or for a single form you might set the form edit/delete etc properties depending on the user ID and the record being viewed.
 

isladogs

MVP / VIP
Local time
Today, 08:37
Joined
Jan 14, 2017
Messages
18,186
Yes in theory its possible ...
You would need to add a field recording the ID of the person that enters the record originally - lets call them XXX

When the form is opened, controls are unlocked for that record if its XXX but locked for everyone else

OR probably a better option, by default the form is locked for all users.
Add an EDIT RECORD button which is disabled for everyone except XXX.
When XXX clicks it, the form is UNLOCKED for that record ONLY

However, there WILL be times when you need to overwrite this
e.g. XXX is away on holiday / ill / leaves the company and the record needs editing
SO also build in an ADMIN USER who can EDIT all records

EDIT:
Just read CJ_London's very similar response - great minds (and mine) think alike....
 

The_Doc_Man

Immoderate Moderator
Staff member
Local time
Today, 03:37
Joined
Feb 28, 2001
Messages
27,001
Adding to ridders and CJ London comments:

If the record is marked with the original name/ID of the person who entered it, and the form is NOT continuous but is rather of the one-record-at-a-time style, then you can put code in the Form_Current routine to decide whether to allow edits or not. See, for example, the form's Me.AllowEdit property (and the other .Allowxxxx properties).

Absolutely concur that you MUST prevent the users from seeing the navigation form or ribbon if you want to control this. Which IMPLIES that you will need a "design master" that you use for maintenance of the front end, but when you publish the front end you would copy the design master and diddle/publish the copy.
 

pottsr09

New member
Local time
Today, 03:37
Joined
May 19, 2017
Messages
4
Thanks for getting back to me!

I will give it a go and see how far I can get. I am still pretty new to access so learning something everyday. I already have my tables, forms, and reporting done just need to tweak it the way you all have suggested. If I have any issues I will be sure to ask.

Thank you all so much!
 

pottsr09

New member
Local time
Today, 03:37
Joined
May 19, 2017
Messages
4
So I have a "Login Form" setup and that is working in my database, but I am having issues on my entry form where it only allows the user logged in to edit their own data.

Can someone give me some help with this?

I am using VBA scripting for the login form to check the username and password as well as an access level assigned to that username to allow access to the proper forms. I like it this way, but I am not against changing it if anyone has any suggestions.

Thanks!

Ryan
 

The_Doc_Man

Immoderate Moderator
Staff member
Local time
Today, 03:37
Joined
Feb 28, 2001
Messages
27,001
Your problem isn't likely to be so much of a login design issue; it is probably a specific implementation issue with that form. Is the same form capable of either entering or editing data? If so, then your problem is in the way you set up to enter the data.

The form's method of blocking action should be that it displays data for every record but, for extant records not created by the current user, it should LOCK the controls (control.Locked=True). You can do this in the form's OnCurrent event, which gives you the chance to look at the current record before the user sees it so you can test whether editing would be allowed.

In theory, if you try to create a new record, when the form navigates to that new record it exists already but is empty. So if you test for who is allowed to edit the record and the record is marked with no owner, claim the new record and let editing happen.

Not saying you SHOULD do this, but if you used command buttons to trigger SAVE, UNDO, CREATE, and DELETE actions then the trick would be that you don't disable the CREATE button regardless of record ownership. (But you DO disable the SAVE button.) Search this forum for discussions of preventing navigation on a form. There are command-button wizards to perform every one of those functions I just named. Might be worth a peek, even if you later decide it is too much of a pain in the toches.

The idea of checking username, password, and access level from a table is almost perfect. Almost. IF you have a domain-based environment or other strict login security where you have your user id and password in order to even use the machine you are on, there IS one improvement to be made. If you don't have this situation, you don't need to do anything different.

IF AND ONLY IF you are in a domain environment or a strict login environment, you can bypass a login screen completely and instead get the username from Environ("Username") to see who is logging in. For "strict login security" cases, that person had to have already logged in with a username and password or some other multi-factor authentication method of getting in. You can take advantage of that strict environment and "trust" the login. Then your username becomes that person's login name. You can have actual names in your table of roles and user IDs and such in case you need to use that info, but otherwise you can have a very smooth and trustworthy login.

If this DOES NOT APPLY to your situation, change nothing in your general design. Just understand that for Access, it would be good to establish some sort of scrambling algorithm for the passwords because a good or persistent hacker would be able to see passwords pretty easily if they wanted.
 

pottsr09

New member
Local time
Today, 03:37
Joined
May 19, 2017
Messages
4
Thanks for the information. I will give it another go and see what I can do to make it work.

We are in a Domain environment, but this database doesn't have to be super secure as it is mainly to be used as a ticketing system for us Tech support reps. There aren't many of us so I decided using an Access Database would be more beneficial as opposed to going and buying some expensive software that we don't really need.

That being said I will have it setup to where depending on who created the new ticket it will auto populate their name by looking at who is logged in. Would it be helpful if I included a copy of the Database for you to review?
 

The_Doc_Man

Immoderate Moderator
Staff member
Local time
Today, 03:37
Joined
Feb 28, 2001
Messages
27,001
No. I don't review databases in that way. I am a bit picky about downloading other people's code. Not that I suspect you of anything at all, but it is just not something I do. Each of us helps in our own way. This is mine.
 

Users who are viewing this thread

Top Bottom