• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 244
  • 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.

  • 2
1 Solution
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.
Did this answer your question?
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Get 10% Off Your First Squarespace Website

Ready to showcase your work, publish content or promote your business online? With Squarespace’s award-winning templates and 24/7 customer service, getting started is simple. Head to Squarespace.com and use offer code ‘EXPERTS’ to get 10% off your first purchase.

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