How do you save logged in user ID for later use? (1 Viewer)

[apr pillai]

It is possible to create Custom Properties on Form and Store and Retrieve Values on Open/Close Events and I use them for different purposes. UserIDs, Passwords or any other value we like to store and retrieve them as and when needed.

Few examples here: Saving Data on Forms Not in Table
Creating Using Form Custom Properties

Create any number of Properties with proper data type as needed.
sample code:

Public Function CreateProp()
Dim db As Database, doc As Document
Dim prop As Property

Set db = CurrentDb
Set doc = db.Containers("Forms").Documents("Employees")
Set prop = doc.CreateProperty("EmpCode", dbLong, 1)
doc.Properties.Append prop
doc.Properties.Refresh

Set doc = Nothing
Set prop = Nothing
Set db = Nothing

End Function

 

[gemma-the-husky]

I declare a typed variable and use that.

type TUserLogin
     userinitials as string
     username as string
     userlogontime as date
     useractiveform as string
     etc
end Type

public ActiveUser as TUserLogin

however, if you have a user table, then you could alternatively save a lot of this stuff in the user table, and all you need to have is a reference to the active user ID.

 

[Gasman]

So would use something like

ActiverUser.username = "Smith"

 

[Micron]

I declare a typed variable and use that.

type TUserLogin
     userinitials as string
     username as string
     userlogontime as date
     useractiveform as string
     etc
end Type

public ActiveUser as TUserLogin

however, if you have a user table, then you could alternatively save a lot of this stuff in the user table, and all you need to have is a reference to the active user ID.

That doesn't look to be far removed from having a class with full project scope.

 

[gemma-the-husky]

Well you have to have something with full project scope.

If all you want is the windows user name then you can just use environ("username"). Otherwise you need a way to sore the login credentials. If you don't need to use the login once you have gained access, then you don't need to store the log in details.

 

[Micron]

Well you have to have something with full project scope.

Agreed, but I was thinking your suggestion is close to where I was about 36 posts ago (#9). I guess I have to wonder why it sorta fell on deaf eyes.


What's also interesting is that I got a notification email concerning a log comment by someone else but it isn't here.

 

[deletedT]

If all you want is the windows user name then you can just use environ("username").

As I explained earlier some of our PCs are shared PCs. They are in manufacturing shop etc and different users login to the access database with the same windows username. They use barcode scanners to register and then logout of access. So I can not use windows user name for these shared PCs.

Otherwise you need a way to sore the login credentials. If you don't need to use the login once you have gained access, then you don't need to store the log in details.

I'm sorry, but I don't really understand what you are talking about. I think you need to read my question once again carefully.

I need to refer to login credentials and I was asking to see how other programmers are saving these credentials to refer to for later use.

In my case once a user logs in to his account, I need to refer to his user ID to be able to disable/enable controls on different forms (according to his permissions) to be able to let him do this or prevent him to do that.

At present I've changed to using tempVars (thanks to DBGuy for his suggestion) to recognize who has logged in.

 

[deletedT]

It is possible to create Custom Properties on Form and Store and Retrieve Values on Open/Close Events and I use them for different purposes. UserIDs, Passwords or any other value we like to store and retrieve them as and when needed.

Few examples here: Saving Data on Forms Not in Table
Creating Using Form Custom Properties

Create any number of Properties with proper data type as needed.
sample code:

Public Function CreateProp()
Dim db As Database, doc As Document
Dim prop As Property

Set db = CurrentDb
Set doc = db.Containers("Forms").Documents("Employees")
Set prop = doc.CreateProperty("EmpCode", dbLong, 1)
doc.Properties.Append prop
doc.Properties.Refresh

Set doc = Nothing
Set prop = Nothing
Set db = Nothing

End Function

I never thought of this method.
I just don't know how to thank you for bringing it up. I'll take a look to see how can I use this.

Million thanks again.

 

[The_Doc_Man]

some of our PCs are shared PCs. They are in manufacturing shop etc and different users login to the access database with the same windows username. They use barcode scanners to register and then logout of access

Are the barcodes always unique per person? Even though they log in as the same username on a machine that will be used by more than one person under that same name, if the barcodes are different, then you just remember the barcodes. Or use them to look up the user's "real" ID in a user table. In any case, you have been given several ideas on how to save whatever you are using as an ID. If you are trying to tailor each user's experience in some way (by allowing blocking certain functions per user), then all the complications in the world don't make a difference. If you cannot uniquely identify the person then you can't get there from here.

It doesn't matter whether you use a typed login name and password, a keyed ID, a smart-card ID, or a barcode scanned ID. SOMEWHERE you will get an ID. And whichever of the many methods described to you that you choose will be what you use to store that ID.

EDIT: After re-reading this, it sounds a bit more harsh than what was actually intended. Tera, there are dozens of ways to do this. To my way of thinking, modifying the form at login time is overkill.

If you use a "switchboard" or "dispatcher" style of form, where you click a button to do a function, then at user connection time, you could make that switchboard smart enough to turn on or off the buttons appropriate for that user. Then allow the switchboard to bring itself to the rear so that any other form is on top. But if the switchboard never exits, you can keep the user ID in that form. At least for the forms where the decision is use/not use, that is really all you need.

 

[deletedT]

Are the barcodes always unique per person?

The bar code scanners have nothing to do with login process. The barcode readers are being used for production line to input Order No, Customer ID, Quantity, etc. I mentioned it just to clarify why some PCs are shared. These PCs are connected to Laths, Fraise, Grinding machines etc. And MUST be shared between the personnel who use those machines.

If you use a "switchboard" or "dispatcher" style of form, where you click a button to do a function, then at user connection time, you could make that switchboard smart enough to turn on or off the buttons appropriate for that user. Then allow the switchboard to bring itself to the rear so that any other form is on top. But if the switchboard never exits, you can keep the user ID in that form. At least for the forms where the decision is use/not use, that is really all you need.

I have a switchboard, but it's impossible to make it smart enough to do what I want. The database has 164 forms and 50 reports and 86,000 lines of codes. I have 6783 controls on different forms with a ribbon that is made of a xml file with 968 lines. All of these forms/controls & ribbon controls should be controlled per user. No matter how the switchboard is smart, it will not be able to control the database.


I know my English is not that good, but I was sure what I asked for is clear enough. But it seems I was wrong.
The system I have, works perfectly and everything is under control. The 86,000 lines of codes are managing just OK. Every user logs in with his/her username and password. His/her user ID is saved and anytime he opens a from, the form's on-open event gives him the permission he has. some controls get hidden, some are disabled, and he gets the edit or read permission for several fields.

I thinks things got mixed up in the middle of the way.
As my first post in this thread says, I'm not asking how to login or how to get permission per user etc. I only wanted to see how other programmers keep a track of a successful login to refer to it in later use.

Let's keep everything simple and clear.
A user logs in. He opens a form and edits a record. The form sets the LastEditBy field to the ID of the user.
Well....How do you understand who is the user?
This was my main question.

At first I was using a global variable to keep the user ID and use it in these cases, but recently I changed it to tempvars. (thanks to DBGuy).
I was asking how many other ways are possible.

 

[gemma-the-husky]

@micron

However, I don't see the point in login forms, resetting forgotten passwords for forgetful users, letting in anyone who is capable of just creating a new password, etc. if it's not necessary, and much of the time it is not. In those cases, I'd just get the Windows Login ID of the user and look it up in the user table. If it's not there, they don't get in.

I have never looked at it, but others have said it is easy to spoof a user name (Environ("username"), but I use it quite regularly.

I don't think it's a question of other FM's ignoring you. Sometimes people skip over some comments without necessarily realising the significance.

 

[gemma-the-husky]

@micron. However, I am now confused, as post #51 looks very like your post #9!

 

[Micron]

Looks like the wrong post was quoted? Not sure what you're saying in 52 as you seem to be the one who quoted in 51. Is there a forum issue or did you have too many wobbly pops?

 

[gemma-the-husky]

Looks like the wrong post was quoted? Not sure what you're saying in 52 as you seem to be the one who quoted in 51. Is there a forum issue or did you have too many wobbly pops?

lol.

I think #51 was the deleted post just above from santinaForendo, which was virtually a repost of your #9

 

[The_Doc_Man]

Tera, I empathize with you, as this is beginning to sound like a really seriously confusing problem. Part of the confusion is your original question, what you want to do about that login.

Here is my point of confusion: When someone uses one of these "open" terminals, does it matter who they are? Because your posts SEEM to be saying that you can't log them in as individuals (because they share the same login). Yet in other posts you seem to care about customizing per person. But that can't happen if you don't know who someone is. I know you worry about retaining an ID (which was the thrust of your original question). But I don't see that you have an ID to retain.

My previous comment was simply this: For the question to have ANY meaning, I must assume that you have a way to determine who someone is. You have seen several suggestions about retaining an ID including Public variables, TempVars, and a user-defined structure, plus a few other ways of retaining this user ID, so I know that you have some ideas that will lead towards your goal.

But the level of customization you are trying to manage is what seems to be giving you trouble. I see it coming through your comments. For you to have counted the hundreds of lines of code in your XML and to consider over 6700 controls and over 100 forms, I can hear your frustration at the customization workload.

Your simple question has been answered. It is up to you to decide when you are ready to pursue other ways of per-user customization that are less time-consuming.

 

[deletedT]

Tera, I empathize with you, as this is beginning to sound like a really seriously confusing problem. Part of the confusion is your original question, what you want to do about that login.
I appreciate you for all your comments and the others who participate in this question. And I'm really sorry for causing confusion. and as my first post says, I know how to do it. I'm looking to see how others do it. Just to clear it once again, I haven't any problem with what I'm doing. I was just trying to learn some thing new, something that pros like you or others would do in this situation. So far using tempVars was great.

Here is my point of confusion: When someone uses one of these "open" terminals, does it matter who they are?
Yes, It matters. I need to know who edits a record.

Because your posts SEEM to be saying that you can't log them in as individuals (because they share the same login). Yet in other posts you seem to care about customizing per person.
Somebody suggested to use environ and check who is loged in to windows. I explained that because some PCs are shared (terminals) windows username is the same and I can't use environ.
I explain it once again. Even from these open terminals, At present the users launch the database, select their name from a combo box, type their password and if the password is OK, they can continue using the database, (according to their permissions). When they are finished with their job, they click a button in the ribbon or the switchboard, log out of database (not windows).

I know you worry about retaining an ID (which was the thrust of your original question).
Yes, it was my main question. How many different ways can be used to retain an ID after a user log in a front end? Global variables, Tempvars, using a hidden textbox in swichboard. How many other ways can be used?

My previous comment was simply this: For the question to have ANY meaning, I must assume that you have a way to determine who someone is. Yes I have. As I explained above, everybody has to log into FE to be able to use it. You have seen several suggestions about retaining an ID including Public variables, TempVars, and a user-defined structure, plus a few other ways of retaining this user ID, so I know that you have some ideas that will lead towards your goal.Yes, those were the exact things I was looking for. I didn't think of tempvars and user-defined structure. Maybe I had to mark the question as Solved, but I thought someone may appear with a new thought. That was why I kept the thread open.

But the level of customization you are trying to manage is what seems to be giving you trouble.Once again. I'm sorry for causing confusion. I have no problem. Everything is just OK and the system is running without any flaw. I was just trying to learn some other ways for retaining ID after a successful log in to FE.

Your simple question has been answered. It is up to you to decide when you are ready to pursue other ways of per-user customization that are less time-consuming.
Well, I think you are right. I was hopping to find some new methods I'm not aware of, but so far so good. I learned tempvars and user-defined structures can be used too.

Once again thanks to all who shared their knowledge and experience.

 

[The_Doc_Man]

You have completely clarified the "login" question. Let us know if or when you want to attack the "dynamic customization" problem.