I'm trying to create multi user logins in Access

[Jonk7273]

I am trying to create multi-user logins in access 2010. each user will have there own login ID and password. when they login in there name and employee ID will be shown on the form I created so that they will not have to choose there name and ID again. cannot seem to get it to work...is there any simple way of doing this...does anyone have any code to help me out?

[RuralGuy]

Have you looked here yet? http://ms-office.wonderhowto.com/how...access-261651/

[orange]

Great link Allan!

[Jonk7273]

That helps, however I need the employees name and employee ID to be shown in the text boxes of the form once they log in...any way I can do that...by the way thank you so much for the fast response it is helping

[RuralGuy]

Google is your friend! 8^)
Thanks!

[RuralGuy]

I have a hidden form that loads before any other form and is used for housekeeping. If this form were running the LogIn then it could hold the values you need on your forms and is easily referenced by any running form.

[Micron]

If you don't have a user table, you should. As you progress, you will find more and more reasons for accessing it. Here's most of the field names for one I use:

LoginID

Perm

Fname

Lname

Level

Active

LoggedIn

SndReqEmail

SndRgaEmail

ContCntr

Email

The loginId is the computer loginId (Google fosUserName). I get that value and query tblUser. If they're not there or they're inactive, they don't get in - no password needed, or will be forgotten, or needs to be renewed. Level allows some functionality and not other. LoggedIn lets me know who's in. Fields 8 and 9 determine if they get certain emails when required. Last field is the email address. If you think this table could prove useful down the road, better to start now.
RuralGuy's suggestion to hold any of these values would work and is probably the easiest. If you progress enough, you can create a custom user object and assign all the user properties to it on startup. This is what I do and if I want to put their name in a textbox, I'd write Me.ctlMyControl = dbUser.Fname

[Jonk7273]

If you don't have a user table, you should. As you progress, you will find more and more reasons for accessing it. Here's most of the field names for one I use:

LoginID

Perm

Fname

Lname

Level

Active

LoggedIn

SndReqEmail

SndRgaEmail

ContCntr

Email

The loginId is the computer loginId (Google fosUserName). I get that value and query tblUser. If they're not there or they're inactive, they don't get in - no password needed, or will be forgotten, or needs to be renewed. Level allows some functionality and not other. LoggedIn lets me know who's in. Fields 8 and 9 determine if they get certain emails when required. Last field is the email address. If you think this table could prove useful down the road, better to start now.
RuralGuy's suggestion to hold any of these values would work and is probably the easiest. If you progress enough, you can create a custom user object and assign all the user properties to it on startup. This is what I do and if I want to put their name in a textbox, I'd write Me.ctlMyControl = dbUser.Fname

Thank you very much this is very helpful!! However do you know where there are any how to videos on how to do what you just explained to me? Please forgive me...I am a novice at best and I really do appreciate your help.

[HiTechCoach]

If you don't have a user table, you should. As you progress, you will find more and more reasons for accessing it. Here's most of the field names for one I use:

LoginID

Perm

Fname

Lname

Level

Active

LoggedIn

SndReqEmail

SndRgaEmail

ContCntr

Email

Micron,
Curious why you are are suggesting duplicating the data that is already in the employee table (hint: OP mentions employee ID in first post). Why not follow the rules of normalization?

IMHO, Security must be a deeply integrated part of the initial design. To be secure it really needs Built into the foundation of the application. Just like the JET User Level Security was always used. There was no way to turn it off.

It has been my experience that security is often added as an afterthought. It is bolted on from an existing generic example that has its own user table.

@onk7273, I would recommend that you use your employee table. Avoid creating a new table that has many of the same fields.

[Micron]

Boyd, you would be correct except that I'd say I'm not doing that. Jonk7273 said what he/she was trying to do, not stating what he already had so I took it that there are no such tables yet. If there is already a table of employees, I still might not agree. If it's a large company with many employees and his employee table has hundreds of records but only 10 are going to use this db, I'd still have a table of users. Otherwise there would be hundreds of records with empty fields for those who are not users of the db, or don't have passwords assigned. On the security side, the password or login validation methods provide the same level of security, which is low. If password is good enough for poster, validation is too - unless he decides to take another route after your valid point. Based on his proclaimed lack of experience, I doubt he is creating any mission critical applications at this point, and we all have to start somewhere...

Thank you very much this is very helpful!! However do you know where there are any how to videos on how to do what you just explained to me? Please forgive me...I am a novice at best and I really do appreciate your help.

Sorry, I know of no such videos. After you consider Boyd's and my comments about security, let me know if you want me to put something together.

[HiTechCoach]

Otherwise there would be hundreds of records with empty fields for those who are not users of the db, or don't have passwords assigned.

I have not had that issue. If it did happen, that would indicate data was not properly normalized. into a related table. This is one of the few times a 1:1 relationship between tables can be useful.

[Micron]

You're saying if there are 100 employees and 10 users you would give every one of them a password? I must not be understanding you. Sorry.

[HiTechCoach]

You're saying if there are 100 employees and 10 users you would give every one of them a password? I must not be understanding you. Sorry.

Yes. An alternative is to have the user info is in a related table with a 1:1 or 1:Many relationship between tables.

The key is that the user is linked to the employee to eliminate any duplication of data.

Question:
Have you ever seen a database that has data in every field in ever record in all table?

Even is you have 500 employees with only 25 that are using and the user id and password field in the same table it would have minimal, if even detectable, impact due to data compression. I find the duplication of the 25 user's information into a user table generally has a larger impact on the database than the two extra fields added to the existing table.

[RuralGuy]

And remember, there is no penalty for empty fields. Access does not allocate fields to the table unless you have data for the field.

[Micron]

Yes. An alternative is to have the user info is in a related table with a 1:1 or 1:Many relationship between tables.

I think I called that tblUser in the beginning, which you didn't seem to care for.

The key is that the user is linked to the employee to eliminate any duplication of data.

Not vital. Where I last worked, the employee table record count was about 45,000 (no, no typo there) and was not editable by anyone outside of personnel. My applications worked just fine without worrying about any duplication.

Question:
Have you ever seen a database that has data in every field in ever record in all table?

No, some had more holes than data.

I think that your paradigm and mine are quite different from a business environment point of view, but both are relevant. What you have needed to do in your world is not always applicable everywhere, so a little flexibility may be in order. I also respectfully suggest we drop this lest we hijack this thread by debating an issue that doesn't help the OP.