How do you save logged in user ID for later use?

[deletedT]

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]

Hi. Since Access 2010, I started using TempVars.

 

[The_Doc_Man]

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]

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]

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]

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 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]

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.

 

[Deleted member 147267]

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]

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]

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]

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.

 

[theDBguy]

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]

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.

 

[theDBguy]

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]

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]

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

 

[isladogs]

If you want a simple method of getting database statistics like in your last post, you might be interested in the code sample I have at http://www.mendipdatasystems.co.uk/database-statistics/4594424201.
Its also available in post #2 of this thread https://www.access-programmers.co.uk/forums/showthread.php?t=296860

HTH

 

[deletedT]

If you want a simple method of getting database statistics like in your last post, you might be interested in the code sample I have at http://www.mendipdatasystems.co.uk/database-statistics/4594424201.
Its also available in post #2 of this thread https://www.access-programmers.co.uk/forums/showthread.php?t=296860

HTH

Million thanks.I'll try it on Monday as soon as I'm back to work.

 

[The_Doc_Man]

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.