Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 243
  • Last Modified:

System.mda performance impact

I have a database used by 4-12 people at a time. The system mda file contains all possible users - around 150. Performance is KEY in this database.

Previously I had the system.mda located on the network with the data. The icon on everyone's machine pointed to the network system.mda. This worked GREAT. Maintenance for me was a breeze because any forgotten passwords or requests for new users could be handled immediately.

However - I got the 'great' idea to offload the system.mda to the users machine to save on performance. I can tell that the login screen displays faster - but don't know how much performance gain I'm getting now. I do know that maintenance is turning into a nightmare. Users can use different PCs and now - if they change their password - the change is only reflected on the single machine. Setting up new users is no longer a simple single step process.

My question - What am I gaining besides initial load time savings by putting the system.mda (mdw) on the local machine. Specifically - how often is the system.mda accessed? Is it accessed once at log in - or for every table retrieval?

All comment are welcome - but please don't post an answer unless you KNOW how the system mda/mdw is used.

Thanks!
CEKMAN
0
cekman
Asked:
cekman
  • 2
1 Solution
 
tomookCommented:
As you suspect, the main thing you are saving is time to bring up the logon screen. By having the SYSTEM.MDW locally, you will also save a few milliseconds between when you enter your user name & password and the UI comes up. In my book, this is not enough to trade for simplified administration.

To clarify what is happening, here is the sequence of events when Access starts.
1. Access locates the SYSTEM.MDW/MDA and tries to log in as "Admin" with no password. If it succeeds, skip to step 4.
2. The "Log On" form comes up and asks for a user name and password.
3. Access looks up the user name in the table MSysAccount in the System.MDW (I don't know if SYSTEM.MDA used the same table name). If found, it looks up the password and compares it with the one supplied. If the user name/pw cannot be validated, go back to step 2.
4. The user's SID is read and cached somewhere in Jet.
5. The user's groups are found and the SID's for each group is also cached.
6. The UI starts.

After step 5, the SYSTEM.MDW is not really used, unless you change a password or some such. The SID is the "magic" string <=20 characters long you supplied when you created a user or group. All the permission information is contained in the MDB, keyed by SID.
0
 
tomookCommented:
cekman:
Did this answer your question?
0

Featured Post

VIDEO: THE CONCERTO CLOUD FOR HEALTHCARE

Modern healthcare requires a modern cloud. View this brief video to understand how the Concerto Cloud for Healthcare can help your organization.

  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now