ms access performance and SSD
Hi Folks.
I need to increase an MS Access database performance. (10 concurrent and 10 other users)
The BE (200Mb) is on a shared drive on a newish virtual server (sharing MS Exchange)
Assuming all the normal database optimizations are done, two questions:
1. will a dedicated server improve things much?
2. will an SSD (D: drive) on the new server (just for the Access BE) improve things (much) more (than a 10,000 rpm SATA drive) on this new box.
I realize the existing server specs are vague, but all expert comment and personal experiences are welcome.
thanks
I need to increase an MS Access database performance. (10 concurrent and 10 other users)
The BE (200Mb) is on a shared drive on a newish virtual server (sharing MS Exchange)
Assuming all the normal database optimizations are done, two questions:
1. will a dedicated server improve things much?
2. will an SSD (D: drive) on the new server (just for the Access BE) improve things (much) more (than a 10,000 rpm SATA drive) on this new box.
I realize the existing server specs are vague, but all expert comment and personal experiences are welcome.
thanks
Asked:
Who is Participating?
<<1. will a dedicated server improve things much?>>
Probably not.
<<2. will an SSD (D: drive) on the new server (just for the Access BE) improve things (much) more (than a 10,000 rpm SATA drive) on this new box.>>
That's hard to say. Depends on the client stations and the network. Remember, with a JET/ACE BE, all DB processing is done by the client. The server is just a file share. It does also take care of holding locks, so if you have a CPU that is bottle necked, you would be better with a faster/seperate server.
<<Assuming all the normal database optimizations are done, two questions:>>
I would focus first on all possible optimizations in the code. For example, do you hold open a persistent connection to the BE for the life of the app? If not, depending on the app, this can give a good jump in performance.
Some other things:
1. Do you have "UseTransactions" set to no on queries where it doesn't matter if they are re-run?
2. Do you open recordsets as snapshots?
3. Do you use CurrentDB() in a loop at all?
4. Are you using a lot of Domain functions (ie. Dlookup) or use them in queries?
5. Compact and repair on a regular basis?
6. checked indexing?
7. Modified all queries so they recost since the DB has grown?
Food for thought...
Jim.
Probably not.
<<2. will an SSD (D: drive) on the new server (just for the Access BE) improve things (much) more (than a 10,000 rpm SATA drive) on this new box.>>
That's hard to say. Depends on the client stations and the network. Remember, with a JET/ACE BE, all DB processing is done by the client. The server is just a file share. It does also take care of holding locks, so if you have a CPU that is bottle necked, you would be better with a faster/seperate server.
<<Assuming all the normal database optimizations are done, two questions:>>
I would focus first on all possible optimizations in the code. For example, do you hold open a persistent connection to the BE for the life of the app? If not, depending on the app, this can give a good jump in performance.
Some other things:
1. Do you have "UseTransactions" set to no on queries where it doesn't matter if they are re-run?
2. Do you open recordsets as snapshots?
3. Do you use CurrentDB() in a loop at all?
4. Are you using a lot of Domain functions (ie. Dlookup) or use them in queries?
5. Compact and repair on a regular basis?
6. checked indexing?
7. Modified all queries so they recost since the DB has grown?
Food for thought...
Jim.
Thanks Pat and Jim; valuable input.
Jim, 2 questions:
1. what does 'Modified all queries so they recost since the DB has grown?' mean?
2. Is the best way to implement 'a persistent connection to the BE' via a bound field on the main form to a 'dummy' BE table?
thanks
Jim, 2 questions:
1. what does 'Modified all queries so they recost since the DB has grown?' mean?
2. Is the best way to implement 'a persistent connection to the BE' via a bound field on the main form to a 'dummy' BE table?
thanks
1. When you create a query and save it, Access calculates an execution plan for how to perform the query. The best execution plan could change over time as table row counts change and indexes are added. So, depending on how rapidly your BE grows or what design changes you make to the BE, you might want to consider compacting the FE periodically to force it to recalculate the execution plans.
2. I use my login form to do this. The form is bound to the user table and when the user logs in, I open the menu but I don't close the login form, I just set its .visible property to False.
2. I use my login form to do this. The form is bound to the user table and when the user logs in, I open the menu but I don't close the login form, I just set its .visible property to False.
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.
All Courses
From novice to tech pro — start learning today.
1. LAN speed and available band width
2. Local Memory
Since all Access processing takes place on the local PC, the server used to host it is almost immaterial.
Make sure the application is split properly - meaning that each user has his own personal copy of the FE.
Make sure that the forms are bound to queries with select criteria to minimize the records selected.
Make sure none of your queries include domain functions such as DSum()
Make sure that your code loops are optimized
Use update queries rather than code loops for bulk updates.
Consider moving the BE to SQL Server - BUT - you will need to do all of the above and possibly other things to actually achieve better performance from SQL Server. If your app is slow now, simply converting the BE to SQL Server will most likely make it slower. You need to optimize the app first.
Strangely enough, moving to Citrix might improve performance. When you use Citrix to host the app, ALL processing happens on the Citrix server (assuming the BE is there also) and so network latency doesn't come into play. The only communication between the local PC and the Citrix server is the local PC sends keystrokes to the server and the server sends pictures to the local PC. Data isn't pushed around the network at all. This is why Citrix works so well for remote users.