Access for others

[DevAccess]

Hello

I would like to create one database, where in at first place I would import 16 users with different data into one of the table and then I would like to create a login screen wherein user would be prompt to login with available users from drop down and password which would store in another table with all imported users.

Now I would want the database set up in such way only super user can see all the data which have been imported into the database wherein normal users will see only their record and can edit their own record while super user can edit/update any record.

I would be creating one table with roles and password for the users.

But How Can I make sure only super user can see all the data and normal user can see /edit only own data at a time.

Please advise best way to accomplish this.

Thanks

 

[Uncle Gizmo]

The Northwind sample database from Microsoft has a login system, not quite what you are looking for, but should give you a leg up.

See how to install it Here:-

https://youtu.be/7TwFpLRnyGY

Sent from my SM-G925F using Tapatalk

 

[DevAccess]

The Northwind sample database from Microsoft has a login system, not quite what you are looking for, but should give you a leg up.

See how to install it Here:-

https://youtu.be/7TwFpLRnyGY

Sent from my SM-G925F using Tapatalk

Thanks Gizmo, I know how login works and all what I want is that I want my own record to be editable/updatable my only, only supper users can update/edit all records.

 

[JHB]

How foolproof should it be?
If 100% then use a SQL-server for the back-end, it is really strong and and can be set up to secure data at user level.

 

[The_Doc_Man]

Just remember that to do what you said here:

normal users will see only their record and can edit their own record while super user can edit/update any record

a couple of things have to be true.

1. No user (expect perhaps your super user) ever sees anything but forms and reports, because you have the database come up in a startup form that is a dispatcher or switchboard to other forms.

2. EVERY FORM that has a potential for this to be a requirement must have code that tests the identity of the user on the keyboard and the identify of the user who "owns" the record you wanted to restrict.

I implemented one of these a couple of years ago. The only thing that kept me sane was to build a prototype form with a lot of the identity checking routines already defined in the forms _Load, _Open, _Current, , _Close, and _Unload event routines. I also had to put stuff in each form's _BeforeUpdate routine so that nobody could do a "silent navigate" that saved the current record (in case it wasn't theirs to save). I had to take over the Save and Undo functions to command buttons that appeared on each form. The prototype had these features built in for every distinct function that a user could do from a form. Once I recognized a new function, I would copy the prototype and customize its behavior, but the infrastructure was there in EVERY form.

Since users couldn't see the navigation panel, reports were easier. In that context, the only way to launch a report was from a report-control page, and that page ALSO had the security stuff on in to grey-out any command buttons that the user wasn't supposed to be able to use.

It's a lot of work and I won't lie to you about it. But once I got the prototypes set up right, the work load went WAY down.

 

[Tieval]

If your users all have a RecordID number generated when they are created you can apply this to a field in each record they create, they can only then see records that contain their RecordID number.

User 1 can see records marked 1, edit them et cetera.

The super user is allocated the RecordID * and can therefore see * (all records).