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

Let's also clear some air about "memory sensitive" issues.

TempVars are dynamically created memory-resident (ONLY) structures that occupy memory only if/when created. They grow and shrink in size according to use of the Add/Remove methods applied to the TempVars object.

Public (i.e. global) variables are usually statically allocated (when in general modules) or dynamically allocated (when opening a form/report with a class module) - but in class modules, you can call them Public but they aren't really public anyway. Both occupy space in the workspace virtual memory when instantiated.

The overhead is less for Public variables because of the TIME at which the references are made. The VBA Compiler has extensive symbol tables it uses when building the code but by the time the module gets loaded to memory, those symbol tables are generally not in play for the code. (They ARE in play for the debugger.) But the fact they are not in play for the code is why you can't make a run-time reference to a variable from an SQL statement. You have to build the statement first, THEN run the SQL as a separate step.

There is such a thing as a dynamically created OBJECT; i.e. you have an object variable for which you could use the object = NEW object-structure-name syntax. In that case, the object variable itself is static but the created structure is dynamically created in virtual memory.

So yes, there can be memory consumption differences between the two, but you use them in different ways and the "address binding time" is different, so expect that difference and don't sweat the small stuff. The BIG stuff is knowing that you have a system that allows you to have larger virtual images and that has enough swap space to support what you are doing.
 
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.

Since it's the weekend and I'm at home, I checked it with a remote control software. it's only 75 MByte.

I appreciate your in depth explanation though some parts of it was beyond my understanding. But I thank you for taking your time and explaining.
 
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

For some parts of the statics I mentioned above, I used http://allenbrowne.com/vba-CountLines.html.
and it took about 52 seconds to count the module lines.
But your code did it only in 17 seconds.

I thought you may want to know that.
Once again thanks.

Edit:
Is there difference versions for your code?
the result that is shown in download page is completely different with what I receive:
Forms count, Report counts, Queries, Modules, Macros are not displayed in the result.
 
Last edited:
For some parts of the statics I mentioned above, I used http://allenbrowne.com/vba-CountLines.html.
and it took about 52 seconds to count the module lines.
But your code did it only in 17 seconds.

I thought you may want to know that.
Once again thanks.

Edit:
Is there difference versions for your code?
the result that is shown in download page is completely different with what I receive:
Forms count, Report counts, Queries, Modules, Macros are not displayed in the result.

I've never tried Allen's code but good to know mine is very fast
Not sure what the edit comment means.
You should have got a complete count of all database objects.
What did you get?
Which version/bitness of Access are you using?
 
I've never tried Allen's code but good to know mine is very fast
Not sure what the edit comment means.
You should have got a complete count of all database objects.
What did you get?
Which version/bitness of Access are you using?


This is what I receive :

attachment.php



Access 2019 x64

As I explained I’m using a remote control software. I’ll check it on Monday when I’m back to office.
 

Attachments

  • 1.jpg
    1.jpg
    61.5 KB · Views: 354
Last edited:
Did you copy ALL the items as instructed. In particular you appear not to have copied the table tblSysObjectTypes which is required.

Note that the utility does not count all system tables and deep hidden tables are ignored. I have another utility that deals with those items.

I'm going to do an updated version of this utility with additional info once my Internet connection is finally restored...hopefully in the next week or so.

Also see this item with additional functionality: View All Database Objects
 
Did you copy ALL the items as instructed. In particular you appear not to have copied the table tblSysObjectTypes which is required.

Note that the utility does not count all system tables and deep hidden tables are ignored. I have another utility that deals with those items.

I'm going to do an updated version of this utility with additional info once my Internet connection is finally restored...hopefully in the next week or so.

Also see this item with additional functionality: View All Database Objects

I copied only two modules (mobDatabaseStatics & modVBEcode) and deleted FormttedMsgBox because I have it already. That’s all. I didn’t read the instructions because my PC has three monitors and it was hard to control it via a remote control on my mobile.

I didn’t receive any errors and imagined it’s what it should be.
I’ll give it another try tomorrow morning as soon as back to office.
 
Last edited:
Would I be correct in thinking you could add custom properties to the FE for user name/access level.?
 
Would I be correct in thinking you could add custom properties to the FE for user name/access level.?

For my situation it’s not possible. We have 15 PCs for this database. Some PCs are set for specific users and nobody else use them. 10 PCS are placed in manufacturing shop floor and Sale department. Different users use these PCs to log into database and register/search data. They login into the database and when finished log out to allow other users use it when needed.

So it’s impossible to use custom properties because different users, use the same FE.
 
No, I was thinking of updating the properties as they log in, or is that not possible, read only perhaps?

FWIW I used Tempvars when I had to do this. I thought of them as global variables, perhaps incorrectly.?
I have also used them when queries can be called by more that one form.?
 
So it’s impossible to use custom properties because different users, use the same FE.

I have only loosely Followed the Thread so I may have the wrong end of the Stick - as usual! But it would seem to me that your only solution is to have a table in the back-end that records the permissions available for each user? Now when and wherever a user logs in, the permissions are automatically set from this table. In effect, they can login from any PC and when they do, they will always have the correct permissions.
 
1. Database stats - as you have found out, some of the code works without the table tblSysObjectTypes but for full functionality you currently need the table as well. That may change when I update it.

2. User permissions - agree with the last two replies. Provided users login to your database, it is easy to set user permissions based on user name. Doing so means the permissions are not tied to a particular workstation
 
No, I was thinking of updating the properties as they log in, or is that not possible, read only perhaps?

FWIW I used Tempvars when I had to do this. I thought of them as global variables, perhaps incorrectly.?
I have also used them when queries can be called by more that one form.?

I had the impression of once Custom Properties are set, they can not be changed afterwards. I have to take a look at them once again.

thanks for the hint.
 
But it would seem to me that your only solution is to have a table in the back-end that records the permissions available for each user? Now when and wherever a user logs in, the permissions are automatically set from this table.

That is exactly what I am doing now. But the case is there are too many forms and too many permissions. So at login I can not set all the permission. I set logged in user ID and set the ribbon according to what he/she is allowed to do.

Then in each form's on-open event, I hide/disable some controls and set necessary permissions.

I was eager to know how real programmers like you and others do in this situation.

I appreciate your input.
 
But the case is there are too many forms

A common reason for there being a lot of forms is that you create a form and then, because you need to do something slightly different, you create a copy of it and modify it slightly. Now you have two forms. If you do this quite a bit, you can end up with 10 or 20 forms you don't actually need.

The alternative is to write VBA code which makes slight alterations to the form, this could be hiding or exposing particular controls, it could be providing it with a different record source, things like that.

Once you master this technique, you can significantly reduce the number of forms, and hence the headache!

Sent from my Pixel 3a using Tapatalk
 
in each form's on-open event, I hide/disable some controls and set necessary permissions.

There are two methods (I know of) you could employ which might simplify this process.

Instead of relying on the forms open event, add your own routines, (public functions) and call whichever routine is required when you open the form.

Every single control has a Tag property. You could add a flag or flags even, lots of different flags in the tag property of every control that needs hiding.

You could modify the public function I mentioned just now, and pass through into that public function the particular flag or flags that applied in this particular instance of opening, use the flag(s) to hide or unhide controls depending. I believe isiadog (Colin) has several examples of this method.

With Tags, instead of addressing each control independently, the routines or routines I mentioned above would have code especially written to inspect every single control in your form, look in the tag, identify if it has a particular flag and adjust the control accordingly.

The code if you are not familiar with this method of coding, then have a look for samples in the forum which contain the something like this:- For Each Control in Me.Controls


For Each Ctrl in Me.Controls

Where the me keyword represents the form the code is in.

Sent from my Pixel 3a using Tapatalk
 
Tony (Uncle Gizmo) mentioned my examples based on using the tag property to show/hide or enable/disable groups of controls. You can find one such example at https://www.access-programmers.co.uk/forums/showthread.php?t=293439
I use this idea in conjunction with user permissions and to manage various multipurpose forms. I find it a very useful approach which simplifies coding and reduces the number of database objects (as they can be reused in different ways.

BTW did you have time to look at the database stats utility properly today?
 
Tony (Uncle Gizmo) mentioned my examples based on using the tag property to show/hide or enable/disable groups of controls. You can find one such example at https://www.access-programmers.co.uk/forums/showthread.php?t=293439
I use this idea in conjunction with user permissions and to manage various multipurpose forms. I find it a very useful approach which simplifies coding and reduces the number of database objects (as they can be reused in different ways.
I have a copy of your sample database and at present I'm testing your method on my database .

BTW did you have time to look at the database stats utility properly today?
Sorry, I forgot to report the result. I tested it this morning as I promised. And it was OK.
Now it shows everything.
this is the result I received:

Database summary : 受注管理.accdb
===============================
Path : D:\Receiption\受注管理.accdb
File size = 74112 KB (72.4 MB)
Analysis completed on : 2019/05/21 3:48:52

Tables : 35
Fields : 1421
Records : 549836

Queries : 35

Forms : 164
Form Controls : 6783
Form Modules : 714

Reports : 50
Report Controls : 2615
Report Modules : 188

Macros : 11

Modules (Standard/Class) : 37
Module Procedures : 3336
Total Code Lines : 85461

Relationships : 1

Time taken : 26 seconds
===============================


thanks again.
 
Glad to have helped. I'll let you know when I update the database stats app.

Also do ask if you need any more info on the use of the tag property for managing groups of controls
 

Users who are viewing this thread

Back
Top Bottom