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

deletedT

Guest
Local time
Today, 20:21
Joined
Feb 2, 2019
Messages
1,218
Nowadays having a login system in a FE to control users permission is quite popular. I've seen a lot of posts here and a lot more on other sites. It's very easy to have a login form and verify if an encrypted password matches user's input. Let him in if the authentication passes, or keep him out if it fails.

What I'm interested in here is how do you save the login info (mostly user ID) to control his permissions after a successful login.

Using a global variable, updating user table and saving the session info or use a class are some possible ways. I've also seen some databases that logged in user ID is set in a hidden text box in a form (normally switchboard).

There may be more possible solutions too.
As the title says, how do you keep a track of the user to identify his permissions after a successful login and why you chose this method?
And if possible, some pros and cons of your method over others.

Many thanks for your time.
 

theDBguy

I’m here to help
Staff member
Local time
Today, 13:21
Joined
Oct 29, 2018
Messages
21,358
Hi. Since Access 2010, I started using TempVars.
 

The_Doc_Man

Immoderate Moderator
Staff member
Local time
Today, 15:21
Joined
Feb 28, 2001
Messages
27,001
I put most of my validation subroutines in a general module and put any identity variables as Public variables in that general module's Declaration area. Which is about as "global" as you can get with VBA programming. I used to keep the user identity, user role, Booleans for special permissions, and such things as user nicknames, login terminal ID, login time, .. anything that might conceivably be of interest in later logging operations.

Not the only place they could go, but one of the simplest. The only problem doing that is if you EVER take the dreaded message box that says "DEBUG" or "RESET" you don't dare take RESET because that erases all variables. I believe TempVars could survive such an event. But I was pretty scrupulous about error traps so I never let any errors get that far.
 

deletedT

Guest
Local time
Today, 20:21
Joined
Feb 2, 2019
Messages
1,218
When I was considering a login system for my own database, I read several articles about Tempvars that didn't give me a good impression. I tried staying away from them since then. Maybe a misunderstanding on my side. I'll try to put some time to see how they can help me.

And more over I've never been good enough in error trapping and as The_Doc_Man says, I have the experience of some users receiving that Debug error box and clicking the Reset button.
 

pbaldy

Wino Moderator
Staff member
Local time
Today, 13:21
Joined
Aug 30, 2003
Messages
36,118
Historically I've either put the values on a main menu form that stays open all the time or left the login form open but hidden. I'd try TempVars, but I'm an old dog and that's a new trick. ;)
 

isladogs

MVP / VIP
Local time
Today, 20:21
Joined
Jan 14, 2017
Messages
18,186
I also use global variables though occasionally I've used the hidden form approach.
I've also kept clear of tempvars as I've never really seen a real advantage over using global variables provided good error trapping is employed.
 

theDBguy

I’m here to help
Staff member
Local time
Today, 13:21
Joined
Oct 29, 2018
Messages
21,358
I also use global variables though occasionally I've used the hidden form approach.
I've also kept clear of tempvars as I've never really seen a real advantage over using global variables provided good error trapping is employed.

One advantage provided by the new TempVars over global variables is that TempVars are available in queries and macros without the need for additional VBA functions.
 

deletedT

Guest
Local time
Today, 20:21
Joined
Feb 2, 2019
Messages
1,218
One advantage provided by the new TempVars over global variables is that TempVars are available in queries and macros without the need for additional VBA functions.

But memory consuming.
 

Micron

AWF VIP
Local time
Today, 16:21
Joined
Oct 20, 2018
Messages
3,476
I find it easier to control permissions with a group policy approach, but I suppose that doesn't matter for the method I've used a few times before - and would use again: a user object. Being a custom object means that I can give it a plethora of properties, such as FName, LName, EmplID, UsrLevel, Email - basically anything. It gets initialized on startup. If for example I want to know if user is an Admin (in order to show or not a button) it's just
If dbUser.UsrLevel = "Admin" Then...

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.
 

theDBguy

I’m here to help
Staff member
Local time
Today, 13:21
Joined
Oct 29, 2018
Messages
21,358
But memory consuming.

Are you saying global variables don’t consume memory? What about the helper functions for retrieving global variables? They don’t consume memory either?
 

deletedT

Guest
Local time
Today, 20:21
Joined
Feb 2, 2019
Messages
1,218
Are you saying global variables don’t consume memory? What about the helper functions for retrieving global variables? They don’t consume memory either?

From what I had read about TempVars, they are more memory sensitive. But as I explained it was a long time ago.
This weekend I'm free and will go through them once again.
 

deletedT

Guest
Local time
Today, 20:21
Joined
Feb 2, 2019
Messages
1,218
I find it easier to control permissions with a group policy approach,
Well unfortunately this doesn't work for me. Because the number of groups would be almost the same as the number of users.

but I suppose that doesn't matter for the method I've used a few times before - and would use again: a user object. Being a custom object means that I can give it a plethora of properties, such as FName, LName, EmplID, UsrLevel, Email - basically anything. It gets initialized on startup. If for example I want to know if user is an Admin (in order to show or not a button) it's just
If dbUser.UsrLevel = "Admin" Then...

I'm very interested in this. Do you have a sample database with this method?


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.

Unfortunately I can't use this. We have several PCs in a manufacturing shop and different users must login to the same front end from the same windows account.
 
Last edited:

theDBguy

I’m here to help
Staff member
Local time
Today, 13:21
Joined
Oct 29, 2018
Messages
21,358
From what I had read about TempVars, they are more memory sensitive. But as I explained it was a long time ago.
This weekend I'm free and will go through them once again.
Hmm, "memory sensitive?" As was already mentioned, global variables lose their values when there's an unhandled error but TempVars retain them. If so, I would think global vars would be more "memory sensitive" than TempVars. In any case, I wasn't telling anyone to stop using global vars and only use TempVars anyway. I was just saying I switched to using them since they came out (became available). Everybody's entitled to their own choices, correct?
 

deletedT

Guest
Local time
Today, 20:21
Joined
Feb 2, 2019
Messages
1,218
Hmm, "memory sensitive?" As was already mentioned, global variables lose their values when there's an unhandled error but TempVars retain them. If so, I would think global vars would be more "memory sensitive" than TempVars. In any case, I wasn't telling anyone to stop using global vars and only use TempVars anyway. I was just saying I switched to using them since they came out (became available). Everybody's entitled to their own choices, correct?

Sorry, I didn't mean to offend you. Actually, I changed my own FE to TempVars to see how they can help me as soon as I saw your post above..(for now only mine, not the whole other copies)

I asked this question, because I need your experience and I'm not trying to push my own way to any one by any means. My purpose was to see all possible solutions and choose any solution that seems to work better than mine. I am sorry if I'm causing any misunderstanding.
 
Last edited:

theDBguy

I’m here to help
Staff member
Local time
Today, 13:21
Joined
Oct 29, 2018
Messages
21,358
Sorry, I didn't mean to offend you. Actually, I changed my own FE to TempVars to see how they can help me as soon as I saw your post above..(for now only mine, not the whole other copies)

I asked this question, because I need your experience and I'm not trying to push my own way to any one by any means. My purpose was to see all possible solutions and chose any solution that seems to work better than mine. I am sorry if I'm causing any misunderstanding.
Hi. No worries. As I said, we are all entitled to our own preferences. I don't think I will ever say my methods are better than anyone's. I am here for the same reason as everybody else - to learn from others to help me get better. Cheers!
 

The_Doc_Man

Immoderate Moderator
Staff member
Local time
Today, 15:21
Joined
Feb 28, 2001
Messages
27,001
In modern computers, the amount of memory consumed by TempVars depends only on the complexity of the "Var" being temporarily defined. You can define a TempVar that is a structure holding dozens of component items, or you can define a scalar Tempvar that is just one thing. There is some overhead associated with the fact that the Tempvar items are named (so you need a name table in memory), but it would be rare for you to actually run into a big issue with consuming too much memory unless you tried to store whole tables in TempVars.

Now if you open up several workspaces or several databases at once using VBA from a single session, then I would worry about memory consumption because of the overhead structures requiired. But for a "vanilla" DB with a few TempVars? No biggie.
 

deletedT

Guest
Local time
Today, 20:21
Joined
Feb 2, 2019
Messages
1,218
But for a "vanilla" DB with a few TempVars? No biggie.

It's one of my databases:

18 local tables
83 linked tables to SQL server
164 Forms
51 Reports
10 Macros
33 Queries
26937 lines in 35 stand-alone modules
54807 lines in 157 modules behind forms
2131 lines in 44 modules behind reports

My largest table has 121571 records


:D
 

Attachments

  • 2019-05-18_13-31-12.jpg
    2019-05-18_13-31-12.jpg
    10 KB · Views: 493
Last edited:

deletedT

Guest
Local time
Today, 20:21
Joined
Feb 2, 2019
Messages
1,218

The_Doc_Man

Immoderate Moderator
Staff member
Local time
Today, 15:21
Joined
Feb 28, 2001
Messages
27,001
Actually, the simplest way to let us see how much space you would potentially take up is to tell us the size in KB or MB of the front-end file. If the answer for the FE is less than 500 Mbytes then you should have no issue with having a few TempVars, or even a few HUNDRED Tempvars. The linked SQL Server tables won't affect the space available for TempVars because they aren't a part of the workspace, which is to say, SQL Server tables are not front-end stuff. They contribute only a few TableDef structures, which aren't that big. TempVars are part of the dynamic FE structures built in memory at run-time so they are REALLY just part of your virtual memory space.

If you go hog-wild and try to build THOUSANDS of TempVars then I would question the design because at that quantity, you are reaching something that should be in a table anyway. But I looked it up and it APPEARS that TempVars must be scalars that are restricted to either numeric or text data, so forget any earlier comments I may have made about structures.
 

Users who are viewing this thread

Top Bottom