Answered by:
Access 2007 very slow on Windows 7

Question
-
Access 2007 is running very slowly in on two new Windows 7 clients. By slow, I mean the response time within Access - moving from screen to screen is dreadfully slow, taking 30+ seconds on Windows 7 to do what a computer with Windows XP will do in 1 second.
I cannot find any information that addresses the issue.
We have been running Windows XP SP3 clients successfully for almost a year. The speed is virtually instantaneous. The Access file is hosted on a file server, Windows Server 2003, with SQL Server Express 2008. Nothing has changed on the server. The Windows XP clients previously and currently experience no problems.
The first of 2 new computers were deployed with Windows 7, with OS pre-loaded from Dell. Microsoft update was run to update OS and Access. Once discovered that Access was running brutally slow, I used the other new PC to test. Windows 7 freshly installed. Office 2007 freshly installed. Tested - still slow. Ran Windows Update, then re-tested. Still slow.
The issue reminds me of the slowness experienced when we were developing the Access database on my laptop which was running Vista. So, it runs fine on XP, but not on Vista or 7.
I'm convinced the problem is a conflict with Windows 7 on the client, but cannot pinpoint it. I've searched these forums and Google for answers, but have not found any information that has specifically addressed this issue. Can anyone offer assistance?
Thursday, February 3, 2011 1:33 PM
Answers
-
I am having similar problems with Access 2010 (and Access 2003) in Windows 7.
I am migrating a system from XP to Windows 7 and find that queries in the XP based system that would complete in 1 to 2 seconds, take up to 2 minutes to complete.
I have seen your post at http://www.utteraccess.com/forum/Windows-7-Slow-Performanc-t1946404.html and have worked through the comprehensive list of suggestions referenced at Tony Toew's website (http://www.granite.ab.ca/access/performancefaq.htm). I have tried various other suggestions including rebuilding the database, a change to the new database format and different connection types and settings (ODBC, JET)
My application is actually a VB6 front end but the same performance issues occur when the query is run directly in the database. My particular system does not involve network traffic as the host database is a the local PC drive.
My tests show that the same benchmark query is also inconsistent in time of operation. This query returns 4000 records or so from a table of about a 1,000,000 records and takes between 45 seconds to 2 minutes to run.
My tests have shown that the same database that runs efficiently with Windows XP SP3 and Access 2003 SP2 (11.6566.8117) has slow performance in Windows 7 Ultimate (32 Bit) with either the same Access 2003 or Access 2010 (Office Professional Plus 2010 v 14.4760.1000)
Sorry I cannot offer any solution but hope this additional information helps the process. I will post again if I find a solution.
- Proposed as answer by MeatPopsicle77 Thursday, February 17, 2011 4:23 PM
- Marked as answer by Sally Tang Tuesday, February 22, 2011 5:52 AM
Monday, February 7, 2011 11:28 PM -
The solution found for this problem, with grateful assistance from Microsoft Access Support, was to change the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\14.0\Access Connectivity Engine\Engines\ACE\MaxBufferSize to 50000
Testing of the VB application showed that the ODBC key HKEY_LOCAL_MACHINE\SOFTWARE\ODBC\ODBC.INI\ODBC Name\Engines\Jet also needed to be changed (this is the same setting visible on the ODBC configuration and definition form "ODBC Data Source Administrator")
Additonally the first call to any database apparently determined which buffer setting was used for subsequent connections to other databases.
I hope this helps with your Access performance problems.
- Marked as answer by Sally Tang Tuesday, February 22, 2011 5:52 AM
Thursday, February 17, 2011 4:33 PM
All replies
-
I am having similar problems with Access 2010 (and Access 2003) in Windows 7.
I am migrating a system from XP to Windows 7 and find that queries in the XP based system that would complete in 1 to 2 seconds, take up to 2 minutes to complete.
I have seen your post at http://www.utteraccess.com/forum/Windows-7-Slow-Performanc-t1946404.html and have worked through the comprehensive list of suggestions referenced at Tony Toew's website (http://www.granite.ab.ca/access/performancefaq.htm). I have tried various other suggestions including rebuilding the database, a change to the new database format and different connection types and settings (ODBC, JET)
My application is actually a VB6 front end but the same performance issues occur when the query is run directly in the database. My particular system does not involve network traffic as the host database is a the local PC drive.
My tests show that the same benchmark query is also inconsistent in time of operation. This query returns 4000 records or so from a table of about a 1,000,000 records and takes between 45 seconds to 2 minutes to run.
My tests have shown that the same database that runs efficiently with Windows XP SP3 and Access 2003 SP2 (11.6566.8117) has slow performance in Windows 7 Ultimate (32 Bit) with either the same Access 2003 or Access 2010 (Office Professional Plus 2010 v 14.4760.1000)
Sorry I cannot offer any solution but hope this additional information helps the process. I will post again if I find a solution.
- Proposed as answer by MeatPopsicle77 Thursday, February 17, 2011 4:23 PM
- Marked as answer by Sally Tang Tuesday, February 22, 2011 5:52 AM
Monday, February 7, 2011 11:28 PM -
The solution found for this problem, with grateful assistance from Microsoft Access Support, was to change the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\14.0\Access Connectivity Engine\Engines\ACE\MaxBufferSize to 50000
Testing of the VB application showed that the ODBC key HKEY_LOCAL_MACHINE\SOFTWARE\ODBC\ODBC.INI\ODBC Name\Engines\Jet also needed to be changed (this is the same setting visible on the ODBC configuration and definition form "ODBC Data Source Administrator")
Additonally the first call to any database apparently determined which buffer setting was used for subsequent connections to other databases.
I hope this helps with your Access performance problems.
- Marked as answer by Sally Tang Tuesday, February 22, 2011 5:52 AM
Thursday, February 17, 2011 4:33 PM -
Thank you for you responses. Microsoft Support suggested the buffer size. We tried it Monday, but it did not affect anything. I still have an open case with MS.Wednesday, March 2, 2011 3:49 PM
-
UPDATE:
- We installed XP mode on the machine and the Access 2007 database runs great, so it's not a NIC issue
- The database is connecting to a SQL Server Express 2008 database
- We tried Office 2010 with no luck.
- We also tried the Buffer size suggested above with no luck
At this time we are waiting on additional recommendations from Microsoft Tech Support.Wednesday, March 2, 2011 3:56 PM -
Update 2:
We did the following, still not working:
- Downloaded and installed SQL Server Native Client 10.0
- Installed SQL Server Express 2008 R2 - unacceptable performance
- Tried using different server, Windows Server 2008 with SQL Server Express R2, same results
- Created a new Access 2010 file with just one table link to the SQL Server Database, still will not open.
- Tried using Office 10.0
- Tried using an ADP file with just tables and that did not work either
- We will be installing Windows XP mode and using it that way until a better solution comes along
Thursday, March 3, 2011 5:41 PM -
We are having similar problems: both in Access and programs develope using VB6 (DAO)
senerio: we have a access database in 2003 format
2 tables : invoice (80000 records) and invoiceDetail (3400 records)
we use a simple select statement with invoice left join invoiceDetail
first result was fast, after that runing the same query takes 30sec to 2 mins
we already tried messing with maxbuffersize but problem remains
We did further testing, we summary it in few points:
1. problem with query that access large result
2. problem mostly happens if you access the same data again and again
***** new findings
3. Problem Matrix XPP windows 7
Intel core i cpu and sandybridge fast slow
Intel core 2 quad fast fast
AMD CPU fast fast
4. We also tried to limit the application to 1 cpu using affinity, sometimes it helps (depends)
5. seems like the problem is pointing to CPU cache handling.
Thursday, March 10, 2011 2:45 AM -
**UPDATE**STILL NO SOLUTION
I've identified the issue being with a single table in my SQL Server 2008 database. I tried eliminating all columns but the primary key and the table refuses to open in Access. It only has 250 records and other tables with many thousands of records open just fine.
I removed all indexes, including the primary key, and then I'm able to open the table but not able to edit. Once I add the primary key index back in the table refuses to open again. Table opens fine in SQL Server and on Access 2007 XP machines with no problem. To make matters worse it's our primary table for the application.
Friday, March 11, 2011 2:48 PM -
Discovered an issue with opening tables in a Access 2000 DB with Access 2007 on Windows 7 64bit. User does not have administrative access to workstation. When I run Access as myself, an administrator, the tables opened instantly, instead of taking 10 seconds.
Just throwing this out. Not sure what our resolution will be for the user, other than giving local admin to the workstation, which we prefer not to do.
Wednesday, March 23, 2011 5:58 PM -
Thanks, I will ask one of my clients to try it. Unforetunately Microsoft is taking a long time to get back to us, hate to think if it was a mission critical issue how it would impact the business.
One of my clients has bitten the bullet and decided to reformat all of the workstations to Windows 7 32 bit...a real shame.
I've written about this issue on my blog as well:
Monday, March 28, 2011 1:47 AM -
Has anyone or microsoft found a fix for this issue, I have been working on it for a few days with a test machine but still not figured it out. What ive got is a window 7 x64 with Access 2007, I,ve got linked tables to a sql Server version 2008. If i click on a table it can take any where from 30 seconds to up to 2 mins to open up the table. Now here the mind bogiling part. I have another Windows 7 workstation and it will open up the same tables just fine , Soooo im now in the process of trying to compair what is the diffrernce between the two machines. So far the only difference is that one machine is a window 7 Pro , and the other is a windows 7 Ultimate ,, all x64bit. I may try and upgrade the pro to the Ultimate edition and see if this is the fix... I have tryed all the buffer changes and even the hot fix , with still no luck , will be trying the upgrade of windows if i cant find any other thing to check....
- Proposed as answer by Tom Swalls Friday, April 1, 2011 9:34 PM
- Unproposed as answer by Tom Swalls Friday, April 1, 2011 9:34 PM
Friday, April 1, 2011 8:23 PM -
OK Found an article on a hp website that finally fixed my slow access 2007 problems, not sure it will help anyone else but it did help me.
Here is the link to the article. Access hangs and slow to responce
I hope this helps.
THanks.
- Proposed as answer by PAULADAMS74 Wednesday, September 7, 2011 7:06 PM
Friday, April 1, 2011 9:38 PM -
I was experiencing the same issue, tried every solution (Including the update hotfix on Tom Swalls blog) to no avail. My machine was windows 7 x64, running a local install of SQL Server 2008 and MS Access 2003 connecting to my SQL Server via Machine DSN in c:\windows\SysWOW64\odbcad32.exe. Any function that would access data from the SQL server would take around 20 seconds to execute (very painful to use our databases at this point).
I finally gave up and installed Windows XP Mode in Virtual PC. Once I got this running I had to make changes to my SQL Server install in order to connect the Virtual PC to my XP install, and to my suprise this fixed the issue on my Windows 7 MS access 2003 install!
Long story short, one of the changes I made was to enable TCP/IP in SQL Server Configuration Manager. Not sure why this fixed the problem, but it did! (This after about 6 months of poorly running Access application).
I would love to hear insight as to why this fixed the problem.
Thursday, May 5, 2011 2:03 PM -
escuse me for my bad english. i have the same problem, i have back-end with sql server (msde, express 2005, express 2008) and f.e. with access (2003, 2007, 2010) with table connected via odbc, all works fine with xp but in win7 the application in some cases works very slow. I did this test, same version of sql, express 2005 sp4, in two different server one with win 7 64 pro and one with win2003 server, when I work with sql in win7 all works fine and the performances are ok, while I work in win2003 all is very slow. This is not a standard scenario, because i have another application with client win7 32 and 64, sql express 2005 on xp and all works fine in both client. At the first time I thought the problem was resolved changing versione of sql (msde to sql express) but isn't so, the only time that i have find a solution was when I have formatted the server e reinstalled O.S. but can not be the solution. EmanueleWednesday, May 18, 2011 8:10 AM
-
So I found the first mentioned registry key under:
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Office\14.0\Access Connectivity Engine\Engines\ACE\MaxBufferSizeI can not find the second key.
I have no subkeys beneath HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\ODBC\ODBC.INI\ODBC Data Sources
or
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ODBC\ODBC.INI\ODBC Data Sourcesand "ODBC Data Sources" is the only subkey of both ODBC.INI keys
any guidance or assistance would be greatly appreciated.
Thursday, June 30, 2011 11:02 PM -
The ODBC registry key will only be present if you have an ODBC DSN data source.
The same registry settings can also be accessed via the extended options, Buffer Size of the ODBC Microsoft Access Setup form.
(Control Panel / Administrative Tools / ODBC Data Source Administrator / System DSN / Configure)
Saturday, July 2, 2011 7:13 AM -
Hi all,
I have similar problems.
During the day Access 2007 get's really slow.. Sometimes just for 15 minutes and it speeds up again.
Does anyone have Symantec Endpoint Protection installed? Sometimes i get a feeling that it slows down during new definitions..
A large mailbox (Exchange) could also be the suspect!
Aswell as a large profile in Windows 7. (even the local profile files)
Unfortunately i still don't know what is causing the slowdown.
Greets JasperTuesday, August 2, 2011 12:34 PM -
Still no fix on this it seems. I have the same problem. I have 20 XP machines who connect to SQL Express 2008 R2 thru ODBC with no problems. 3 Windows 7 machines are dead slow. I am using SQL Native 10 ODBC client which is light years faster than the standard client, but still unacceptable.
Here is more data for the mix:
1) When I have no internet, the problem is multiplied 10x. Something must be trying to query online, timeout, then it does the query.
2) I have disabled firewall on both server and workstations. No difference (tho Integrated security works better with firewall off on server. Different problem, i think. )
3) There is a randomness on this. Sometimes the query is slow with 1 record results and other times fast. Sometimes 300 row result sets are faster but most times slow. In general 300 row recordsets are much slower than 1-5 row record sets. As well combo boxes based on recordsets are killers.
Paul Batton's post on June 30, 2011 is still unanswered. I too have no subkeys beneath HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\ODBC\ODBC.INI\ODBC Data Sources.
The odbc tool off control panel yields no advanced settings to access to MaxBufferSize.
HELP! Any advice is welcomed.
Thanks in Advance.
Tuesday, August 9, 2011 3:34 PM -
Hi all,
Can a printer driver influence MS Access 2007 performance? Even with opening or closing a form?
I have a suspicion that the HP Universal printer driver is slowing MS Access down.
Monday, August 15, 2011 9:55 AM -
I had a similar problem, in the end I connected using named pipes. This allowed my front end pc's using win 7 to connect to an sql back end. All my xp machines did it with no problem. Any odbc sting written for win7 would either hang or only make a one time connection. If you shut the front end on opening up again you had to relink all the sql tables.
My front end also connects to 2 other access back ends. The win 7 machines seem to forget what they are doing when opening some forms and access has to be shut down. The xp machines never have a problem.
Again paying top dollar for software, but not getting any speed in this being fixed
Friday, August 19, 2011 10:06 AM -
Disable the DpHost Service (Biometric Reader) on HP Machines. This solved the problem for me.
Wednesday, September 7, 2011 7:09 PM -
I was able to solve my problem by using named pipes, as described above. In order to achieve that, you should add "np:" in front of the server name on your connection string. (You may have to relink all your tables.)
There is some code you can use to test the speed of the connection:
cnStr = "Provider=SQLOLEDB;Data Source=np:192.168.0.1;Connect Timeout=10;Trusted_Connection=Yes" dtStart = Now For i = 1 To 50 Set cn = CreateObject("ADODB.Connection") cn.Open cnStr Set cn = Nothing Next dtNow = Now duration = DateDiff("s", dtStart, dtNow) MsgBox (duration & " seconds")
By using the code above, it takes 7 seconds to open the 50 connections using TCP. Using named pipes, it takes only ONE second to open the 50 connections.I hope I could be of some help.
- Edited by mbertuol Monday, October 31, 2011 1:30 PM
Tuesday, September 27, 2011 8:12 PM -
Hi All,
I've been following this thread with great interest as I, too, have this very same issue.
VB 6.0 front end connecting msaccess db over a small multi-user network. So frustrating. Sometimes the search is ok other time slow and other times MINUTES long. All of these data operations functioned in seconds in Winxp. I'm running windows 7 64 bit on Intel i3 processors. I have tried everything - no solution. If this is not solved SOON I am going to have to roll all of the systems back to XP. PLEASE someone find the answer and post it here.
Desperate,
Ddresh
Sunday, October 30, 2011 3:47 AM -
I have found the solution. See message posted on Tuesday, September 27, 2011 8:12 PM. You have to use named pipes in the connection string. Just add "np:" in front of the server name on your connection string. Then relink all your tables and you are done.
Monday, October 31, 2011 1:30 PM -
Hi All,
When you start Windows 7 resource/performance monitor, when Access is slow, does the diskactivity show a lot of svchost.exe (Dcomlaunch)?
When i reboot the computer, Access is fast again, but after some time access slows down, i look in the resource monitor and the dcomlaunch is back.
Since a couple of days i have split up the threat Power/PlugPlay & Dcomlaunch into seperate threats and the problem is far more less.
In my case there is something wrong with the ndis.sys.
To split the threat at the command line:
sc config power type= own
sc config plugplay type= own
Greets Jasper
Tuesday, November 1, 2011 11:03 AM -
'I have found the solution. See message posted on Tuesday, September 27, 2011 8:12 PM. You have to use named pipes in the connection string. Just add "np:" in front of the server name on your connection string. Then relink all your tables and you are done.'
I don't think this option is available in DAO. If it is I would like to know how to do it.
Jasper, I don't understand this method either. Thanks
Thursday, November 3, 2011 5:08 AM -
Ddresh - I'm using DAO and this worked for me:
1. Go to Control Panel
2. Go to 'Set up data sources (ODBC)'
3. Select your data source, click on 'Configure'
4. Click on 'Next>'
5. Click on 'Client Configuration...'
6. Change the Network libraries to 'Named Pipes'
Everything seems to be a lot faster now.. hope that helps.
Thursday, November 17, 2011 11:52 PM -
What a long thread!!!!!!!!!!
I found our solution. (not that it will work for everyone).
But this one is too easy not to try. The problem for us was the conflict between IPv6 and IPv4 in the TCP settings of the network card using Windows 7.
Solution go into the properties of your NIC card and uncheck the box Internet Protocal Version 6 (tcp/IPv6).
Bam!!!!!!!!!!!!!!! Works like butter. Fast again
- Proposed as answer by PeterGdownload Tuesday, April 17, 2012 11:54 PM
Monday, November 21, 2011 3:46 PM -
Guys what i've tried and has FINALLY worked for me is the Max Buffer Size mentioned earlier set to 50000
my set-up: HP i5 Desktop with Win7 x64, Access 2007 and on the server Win2003 R2 with an Access DB in 2003.
Hope that helps.
Wednesday, November 23, 2011 12:00 AM -
For Emanuele Gostoli excuse me too for my bad english, i had the same problem: sql server 2005 on a XP pro Machine, and Access 2007 FE on Window 7 machine. Solution: download sqlncli.msi which installs Sql Server Native Client 10.0 and create an ODBC connection using this driver but be carefull: use IP address instead of coumputer name. This fix my probllems and i hope the same for you.
Carlo
Friday, November 25, 2011 11:36 AM -
Microsoft has acknowledge this as a problem with Access 2002 or any later version and Windows 7/Vista: http://support.microsoft.com/kb/2553116 . A hotfix has been released but only for Access 2010/ACE 14. We don't know if Access 2007/ACE 12 will also get a hotfix.
- Edited by xpclient Wednesday, December 14, 2011 1:29 PM
Wednesday, December 14, 2011 1:28 PM -
After reading numerous forums , I was able to resolve the following issues (Screens Freezing, Screens Lag/Flickers, combo/list boxes freezing whilst searching for data) by carrying out the following:
· Creating a brand new copy of the MS Access database in MS Access 2007/2010 using the Windows 7 image
· Importing the database objects (tables queries, forms, reports, macros and modules) into MS Access 2007 /2010 d/b within the Windows 7 image.
· Setting the MaxBufferSize of 16384 (Decimal), HKEY_LOCAL_MACHINE (regedit) onto various PCs as recommended by various forums.
· Making sure that the relevant reference libraries have been selected for MS Access 2007. This should automatically set throughout the default installation as demonstrated below:
Visual Basic For Applications
Microsoft Access 12.0 Object Library
OLE Automation
Microsoft DAO 3.6 Object Library
Microsoft ActiveX Data Objects 2.5 Library
Also by typing in the following words into Google, provided me with some solutions, however the instructions above allowed me to rectify the issues experienced above.
· MS Access 2007 slow in Windows 7
· MS Access 2007 and Windows 7 issues
· MS Access 2007 freezes
· Performance slow with MS Access and Linked Tables
· Slow performance windows 7 using MS Access
Wednesday, January 4, 2012 1:16 PM -
-
The only thing that worked for me was disabling Kaspersky Antivirus on the client from actively protecting the network location where the Access file was. If I moved the Access file to the local PC, even though active protection was enabled for the local location, the response was fast. It was only the combination of the Access Db on a remote XP machine and Kaspersky protecting that network location that made it painfully slow. I hope this helps somebody.Friday, February 10, 2012 9:06 PM
-
Hi all,
I'm not an Access or DB expert here so please bare with me. We have experienced the same thing and have tried the max buffer method, disabling Symantec AV not to scan folder or .accdb file and copying to a local drive and still slow me thinks.
This is what we have.
New PC is
OS: Windows 7 32-bit with Access 2010. It's a Virtual Desktop with Single Core vCPU.
Old PC is
OS: Windows Vista 32-bit with Access 2007. It's a Physical Desktop with Dual Core CPU.
When opening the database, the performance on the two platforms are equal. But when opening one of the module on the switchboard, the old PC will take 3-5 seconds and the new PC will take 40-45 seconds.
And it seems to be my fault for upgrading them to the newest and greatest of Windows 7 and Office 2010. Lol. So I need to cure this problem. Do you think a Single or Dual Core CPU matters on this case?
Any help would be appreciated.
If I report this to Microsoft support, is that the paid support one? If not, do you have a link where can I get help from Microsoft?
Thanks guys.
Additional info:
I've added another vCPU to the Virtual Desktop so it's running Dual Core just like the Physical PC. It helped a little bit. It's down to 8-10 seconds when opening one of the module on the switchboard. Thought the user is going to be happy with that but they are still not. They think 5 seconds wait time is too valuable so the troubleshooting continues...
- Edited by CP7 Friday, March 23, 2012 8:40 PM
Friday, March 23, 2012 3:30 PM -
Hi everyone
I am running Access 2003 under Windows 7 64-bit and here is what worked for me.
First thing I tried: Searched through registry for all "MaxBufferSize" entries relating to data sources/handling (so ACE, JET 2.0, JET 3.0, JET 4.0 etc...), then I changed the value of each of these to "50000" (decimal)
After this the processing DID speed up significantly :)
Second thing I tried: Went to the "MSACCESS.EXE" in the "C:\Program Files (x86)\Microsoft Office\OFFICE11" folder , right clicked and went to the "compatibility" tab, where I set it to run as "Windows XP SP3", then I also ticked the "run as administrator" box.
After a fresh reboot I tried the same processing procedure and the time taken reduced by 50% :) :)
I may not have needed to change ALL the MaxBufferSize entries to 50000, perhaps it was just the Jet 4.0 that did it? One thing is for sure, I work in a high pressure environment with little or no time for anything other than production work...so now it is working quickly I am not looking back!! lol
Hope this helps some of you out, and good luck to the rest of you!
Sam Kelly
Thursday, April 12, 2012 10:10 AM -
This was the issue for me.
Win64 machine. Access 2007. Symptoms were just opening up a table took about 8 seconds. Disabled the TCPv6 option and things back to instant.
Regards
Peter
Tuesday, April 17, 2012 11:56 PM -
My problem was that after making changes to the VB code for a form, saving each change would take around 2 to 3 minutes.
The above solution got me on the right track. All I had to change was ONE registry setting!
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Office\14.0\Access Connectivity Engine\Engines\ACE]
MaxBufferSize => set this value to 50000 (decimal)I certainly hope this helps somebody out there!
Tuesday, July 3, 2012 11:20 PM -
Sammy-K - you have provided what no-one else could. I have a commercial application which, in W7, was taking 1 minute to return a form that usually comes back in 1s. All other posts say to look at ACE, but we're using VB6 to Jet 4.0, and this is the first time someone said that there could be other Reg keys, not just the Office14/ACE. Jet 4.0 MaxBufferSize fixed it definitively. I set to 50k, super fast again. I set it back to 0, super slow. Over 12 months we have been burdened with this problem on one or two sites and we had no answer. Thank you all so much for a collaborative effort.
- Proposed as answer by AussieTone Sunday, August 12, 2012 12:27 PM
Sunday, August 12, 2012 12:27 PM -
I think most of the people here are referring to a TOTAL breakdown of access 2010 where NOTHING runs fast enough. I know I am exploring finding other software rather than tolerate this. Even clicking on properties of a lable then to another takes 1.5 minutes to redraw. I see this on all 60 of the computers that use this. Futher, I am seeing database becoming corrupt at an alarming rate. I am positive that these posts only represent a small fraction of the people having trouble. Someone at Microsoft had better get it together and find out whats going on.Thursday, August 23, 2012 8:55 PM
-
Sammy K, thanks for the help. Set the buffers and compatibility setting and its back to blazing.
- Edited by howardpetersen Wednesday, September 5, 2012 3:15 PM
Wednesday, September 5, 2012 3:14 PM -
Sammy_K,
I created an account just to be able to thank you for your answer - like other responders here, it has fixed the problem with Access 2003 queries hanging on Win7-64.
For the record, the only thing I did was change the MaxBufferSize entry at [HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Jet\4.0\Engines\Jet 4.0] from 0 to 50000 Decimal. Queries that had taken an abysmal 1-2 minutes before now operate in under 5 seconds.
Thank you again, Sammy_K!
Monday, November 19, 2012 8:59 PM -
This thread is as long as useful.
Till now, no fix by Microsoft for this "BUG".. but following your indications, autofix works fine!
Wednesday, May 15, 2013 2:48 PM -
Hi!
I have the problem reported in this thread, slow Access -- 2010 SP1 -- (64Bit) on Win 7 (64-bit).
I've also installed KB: 2553116, which improve startup performance.
So I try to do the registry key modification and everything goes ok, for the first 4/5 queries. After that Access becomes even slower.. I've tried different MaxBufferSize values, from 20k to 300k, but sooner or later it becomes slow!
Have you got any suggestion?
Marco
- Edited by mserioli Friday, May 17, 2013 3:00 PM
Friday, May 17, 2013 2:59 PM -
This worked for me. I have been searching this for about 6 months now and have tried everything. Disabling the IPv6 settings works! Thank you!Tuesday, June 25, 2013 8:17 PM
-
My problem was solved when I changed language properties of my forms to "system" instead of "English" and "Persian"Thursday, August 22, 2013 7:12 AM
-
You need to set the maxbuffersize to 50000 not 200 or 300.Friday, September 6, 2013 1:23 AM
-
I think I found out the reason : "Keyboard Language" property of the field should be set to "System".
This is what I tried, and "YES" the speed is just fine!
Please spread the world, I have been chasing this for almost a "Year"now!
Good luck
Sunday, October 6, 2013 6:22 AM -
I too had the "combo boxes based on recordsets are killers" problem, and traced it down to using a single global connection for multiple recordsets (which was fine in earlier versions of office). When I changed to use a new connection for each static recordset it's back to its snappy old ways.
It seems maybe Access is applying some properties to the whole connection rather than each recordset in that connection. Maybe its an ODBC or x64 driver problem? but I have not pursued it further.
Monday, March 3, 2014 11:57 AM -
I'll share the fix that worked for me,
When you setup the connection to the SQL Server, use the IP address of the SQL Server machine instead of The Computer Name
Wednesday, March 5, 2014 11:33 PM -
@ MeatPopsicle 77
By updating your registry Engine (ACE):
did you notice a speed improvement for Access?..
I am looking to do the same; I am using a FE/BE where the BE is stored on the network and FE Form on the local machines [desktop]. But i am wanting to make it faster when using the forms.
any help will...help lol
- Edited by Tree of Knowledge Thursday, October 2, 2014 4:02 PM
Thursday, October 2, 2014 4:01 PM -
hi Mahmoud,
can you please provide step by step instructions for the change you mean ?
where is the "Keyboard Language property" which you are talking about ?
many 10x
jaja
Wednesday, November 19, 2014 12:01 PM -
The answer provided above with the registry fix helped me with a legacy POS system issue I was dealing with. Thanks!Saturday, June 10, 2017 5:28 PM