Full Version: Is Access 2010 Slower Than 2000
UtterAccess Discussion Forums > Microsoft® Access > Access Q and A
TimTDP
I have recently upgraded from Access 2000 to Access 2010
Ofind Access 2010 very slow when developing.
It takes a long time to go from form design to view and vice-versa.
Selecting objects on a form, subform in design view take a long time.
Is 2010 slower to develop than 2000?
FOr am I missing something?
MiltonPurdy
I do not know about 2010, but 2007 is a LOT slower.
HiTechCoach
I do not see any difference in speed while developing between the 2003, 2007, and 2010 versions.
That I have noticed will all three versions that seams to help with speed of development:
1) Turn off the auto correct feature.

2) edit the front end from the local hard drive. Not over the network.
Every database I work on is split. Are your databases split?
Are you using the new ACE (.accdb) format or JET (.mdb)?
TimTDP
2) edit the front end from the local hard drive. Not over the network.
The front end is on my local hard drive. The backend is on a network.
Are you using the new ACE (.accdb) format or JET (.mdb)?
I am using .accdb
HiTechCoach
The biggy is #1. Have you turn off the auto correct feature?
dmhowe54
I have just switched to access 2010. I am having the same problem but it is not consistant. I have auto correct off and am using .mdb format because I still have a lot of computers with Access 2003 on them. I have a split database with the backend on my local machine for design changes.
Some forms are as quick as a flash to move between subforms in design view while others can take up to 30 seconds.
There must be an answer somewhere but I can't seem to find it.
HiTechCoach
Complex forms take a while. On load Access does a lot of validation and checking. Control's with record sources, like combo box, list box, and sub forms, do take longer.
Sometimes forms and reports will get corrupted. For forms/reports that are loading really slow, or have had lots of edits, I will back them up to a text file and then restore them. See: Backing up and Restoring Objects
Oalso generally use a development copy of the back end that is on the network. I do not use the live back end that is in use.
AlbertKallal
I can assure you that switching a form into design mode has not significantly changed from 2000 to 2010 in any significant way.
However it is possible there are some increase sensitivities to network when you flip a form in design mode.
So to be clear some big increase in switching is not normal, and there's no access developer worth their salt having used any version of access would even begin to entertain that such large delays would occur due to Access code running slower.
However what has changed is there is an increased in sensitivity on some newer machines due to network issues. In fact it not even clear if it Access that is experiencing these delays, or the windows networking changes caused this.
However thankfully at the end of the day in 99% of the cases you can get rid of these delays with relative ease.
The first thing to check:
Network printer –If you have a disconnected network printer or if your default printer is a network printer that may, or may not be off line, then stop right there. In fact this issue does not even only apply to access 2010, but again I seen an increase in posts in this regards. So, switch your default printer to a local printer. In fact I set my default to a local PDF printer. The reason why this setup can cause a delay is that access when using a form or report can go off and query a significant amount of information about the printer layout information and uses that during design mode to set some things up. So, as a general rule and general suggestion you do well to eliminate this printer network issue.
The other issues since access 2000 that I've been speaking over and over for 10 years is you find significant delays can occur if you do not have a persistent connection to the back end database. A rule to test this is to simply open any table from the front end that that's connected to the back end - now minimize this table, and now try working on any form or report - bottoms to dollars, for those with a split database (and the BE is on a network share), your local delay will go away with this persistent connection trick.
Try the above two, and post back here and see what happens.
The third one that recently came up, is the user assured me that they did not have a split database; upon further inquiry it turned out that user had a few linked tables. And worse a few where linked to nonexistent databases. These were not needed, and when removed once again all delays disappeared. So check for some table links to other databases, and also check for links to nonexistent databases, especially if you're pointing to some nonexistent network share!
So rest assured, on a given machine without any network issues, flipping a form into design mode in access 2010, or access 2000 should not result in any particular notice of difference or change in your user experience during the development process. And in fact I'm quite confident point out that the above two or three issues can and has occurred quite often with all versions of access since 2000, and to my experience access 2010 is not different in this regards.
To answer your question: In the regards afflicting the form into design mode, on modern competent hardware, you should not be experiencing anything of any significant difference that you've experienced in previous versions of access.
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
kallal@msn.com
Davestats
Bless You, AlbertKallal.
Oand my recently departed co-worker have been trying to solve an issue with Access 2010 for at least 6 months. The problem was very slow response times while working in design mode.The initial problems centered around situations where we moved the focus from a form to a subform and back, or to a different subform. The most exaggerated example showed up when I would work on a report from which all fields, recordsources, code had been stripped. It was a report used to print a copy of a full report but with no data entered and was used when there was no full copy available. The first time I changed from print preview to design was quick enough but if I came back to preview and then tried to go to design view it took 4 minutes. There was no sign of any great activity with the CPU but there was this squiggly graph in the network graph of Windows Task Manager. Something was communicating. In December I posted a question on experts-exchange and got many ideas but nothing that eliminated the issue.
He became convinced it was the antivirus or some other spyware checking program but turning them off did not help. Yesterday, I found this question and read until I got to this last post. First, I tried the switch to a local printer with no improvement. Then, I opened a table in the backend and began doing the things that had been met with slowdowns in the past. I have tried enough to convince me this was the issue. I think the communication on the network is consistent with the explanation of the cause.
In any case, I am greatly grateful.
David Isaacs
Jeffersonville, Indiana USA
AlbertKallal
You are most welcome.
reat to see someone follow up since it helps others to learn about this issue.
To be totally honest, I think it's pretty scary, and pretty darn frustrating to upgrade to some new version of anything, and as a result of spending good money you're rewarded with a swift kick in the pants.
I think it's fair to assume that every new version of just about any software you purchase, with few exceptions over the years will always require more CPU Processing, more disk and more memory. In fact I'm hard pressed to think of any version of any software I've ever purchased that the next version did not run slower and require more computing resources.
However, for the most part, a2010 will run rather well on a typical desktop computer and is not "significant" in terms of performance. There are a few possible performance issues, but in general I not encountered anything significant as of yet.
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
kallal@msn.com
Davestats
I have been testing the "solution" and have done so by taking a table in the backend that is no longer used for new actions and keeping it open in the background. The few times I have forgotten to open it I have been thrown back into the delays. It is incredible to think that this difference can cause a simple report to take 4 minutes to go to design mode.
On any case, I am wondering if you see any downside to running code to automatically open this table when I open the database. I will not be accessing any record, allthough no one else should be do so. Also, while my issues all involve switching from report/form views to design and back, is it possible this could help someone running the .accde version?
Lastly, your last comment about Access running rather well on a typical desktop computer brings up another issue. There is another desktop that was used by another person that has Windows 7 (mine has XP) and Office 2010. While I have not seen the same problem I had occur on the 7 machine, I have see repeated, random(?) freezups while in Access of Excel and while doing something rather intense. That machine has 2 GB memory and its baseline usage is a little over have of that. I have read that a 64 bit installation of Windows 7 should have "at least" 2 GB. What are your thought that this is just too little memory to do "intense" things?
Again, Thanks.
Dave Isaacs
AlbertKallal
>is it possible this could help someone running the .accde version?
Yes, it recommend in all applications to force and keep a connection open at all times. So this is standard fair for everyone for about 10 years now. So you want to ALWAYS open up a and ensure a persistent connection exists and we all do this for all of our applications.
So the large delays you see are not limited to just form design, but a simple opening of a form can encounter huge delays on a network with multiple users. You "often" see people say the application runs great with 1 user, and the slow as a dog with 2 users. Again, 9 out of 10 times this behavior is consistently fixed by the persistent connection trick. The basic program is the file system has to switch gears from single user mode to multi-user mode, and a few more issues in regards to file locking has to be setup. This can take ages. If you force this whole process to occur one time and force the connection to be open, then you eliminate this huge dance of locking and setup of the file for use.
So no, the issue is not limited to design time, but also that of just running an application.
>What are your thought that this is just too little memory to do "intense" things?
Well, hard to find a win 7 box with less then 4GIG ram these days. I think 8 gig of ram is $40. Even the budget low end models below $500 have 4 or 6 gig these days.
However, 2 gig should be fine if they don't have a dozen programs running. If the application runs great, but then after loading browser, outlook and everything else it runs slow, then additional ram will help. However, if you JUST run the Access application with nothing else and it runs fine, then more ram likely will not help a lot.
It really depends on how much "junk" is setup and installed on the computer. Installing 1 or 100 programs will not hurt or slow down the computer. However installing 100 programs such as chat clients etc. that startup in the system tray? Well then that computer quite much trashed and ruined already, and 2 gigs of ram will not be enough.
So for a clean computer without tons of junk at startup, and limiting the number of applications runs then 2 GIG should be fine for Access.
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
kallal@msn.com
Davestats
Albert,
took your solution and have been running with it. I found only one time it "might" not have worked. I say "might" because I might have forgotten to open a table. That brings me this: I have tried to automate the opening of the table but when it comes to minimizing, hiding it, making it not visible nothing I have done has worked.
For me I think the issue is that I bypass the startup form, but the problem with everyone else, especially those in a tabbed view, is that I have not found a way to make that tab go away. I can solve the issue of my situation by putting the command to open the field in the Autoexec macro but then it opens when the users open.
Hope you have an idea.
Dave
Davestats
This is off the original subject but wanted to follow up on the issue with how much memory was required to run 2010. After years of using a machine labeled as having 3 GB of RAM but registered as 2 GB and having corporate refuse to add any memory, I got a newer computer with 8 GB RAM. I will not say the issue has disappeared but it is no longer noticable. I still appreciate Albert's solution and have applied it.
ave
olcaym
Hi,
urely I am late for this discussion, but I have the problem now and came here.
1) System: Windows 7 Home Access 2010 Backend: mdb 2000 Frontend: accdb 2010 Original FE was build with 2000. 20 Tables all linked
2) Problem: Open form in design view. To switch to a subform is 20 seconds, than switch back to main form another 20. Just to maximize form takes another 20 seconds.
3) This Topic: I tried everything written in this topic and no result.
4) My Solution: When I open database for design, I use below code to open all tables and minimize. Please note that, to open only the tables attached to form and subforms does not solve the problem
Dim obj As AccessObject, dbs As Object
Set dbs = Application.CurrentData
For Each obj In dbs.AllTables
If Left(obj.Name, 4) <> "MSys" Then
DoCmd.OpenTable obj.Name
DoCmd.Minimize
End If
Next obj
if needed use this code to close all tables
Dim obj As AccessObject, dbs As Object
Set dbs = Application.CurrentData
For Each obj In dbs.AllTables
If Left(obj.Name, 4) <> "MSys" Then
If obj.IsLoaded = True Then
DoCmd.Close acTable, obj.Name
End If
End If
Next obj
Yes, it is messy, but switching to subform is 1 second.
I hope this helps someone
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.