Save 30% on the CV211 using promo code EXPERTS30 now through April 30th. The ATEN CV211 connects a laptop directly to any server allowing you instant access to perform data maintenance and local operations, for quick troubleshooting, updating, service and repair.
Course Of The Month
8 days, 4 hours left to enrollBecome a Premium Member and unlock a new, free course in leading technologies each month.
Solved
ms access performance and SSD
Posted on 2016-08-18
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
[X]
Welcome to Experts Exchange
Add your voice to the tech community where 5M+ people just like you are talking about what matters.
- Help others & share knowledge
- Earn cash & points
- Learn & ask questions
2
4 Comments
Active today
The two things that most effect Access database performance are:
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.
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.
Active 3 days ago
<<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
Active today
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.
Featured Post
Question has a verified solution.
If you are experiencing a similar issue, please ask a related question
It’s the first day of March, the weather is starting to warm up and the excitement of the upcoming St. Patrick’s Day holiday can be felt throughout the world.
In Part II of this series, I will discuss how to identify all open instances of Excel and enumerate the workbooks, spreadsheets, and named ranges within each of those instances.
Using Microsoft Access, learn some simple rules for how to construct tables in a relational database.
Split up all multi-value fields into single values:
Split up fields that belong to other things into separate tables:
Make sure that all record…
Polish reports in Access so they look terrific. Take yourself to another level. Equations, Back Color, Alternate Back Color. Write easy VBA Code. Tighten space to use less pages. Launch report from a menu, considering criteria only when it is filled…
Suggested Courses
Course of the Month8 days, 4 hours left to enroll
728 members asked questions and received personalized solutions in the past 7 days.
Join the community of 500,000 technology professionals and ask your questions.