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?
Experts Exchange Solution brought to you by
Enjoy your complimentary solution view.
Get every solution instantly with Premium.
Start your 7-day free trial.
I wear a lot of hats...
"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.
Experts Exchange Solution brought to you by
Your issues matter to us.
Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.
Start your 7-day free trial
<<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.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Microsoft Access
From novice to tech pro — start learning today.
-
Microsoft ApplicationsCertification: MCSA MCSE Microsoft Certified Solutions Associate & … 398 lessons
Experts Exchange Solution brought to you by
Enjoy your complimentary solution view.
Get every solution instantly with Premium.
Start your 7-day free trial.
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.