Hello Everyone.

This is the first time in a year i post a question, as usually searching the web I will find an answer to my problems.

I have spent a couple of days, searching for problems and solutions similiar to mine, but just cannot find, so here i am.

I have a fairly big db, which includes Front Ends MDB for around 40 users, and a Back End MDB.

All in access 2003 format. All in production Server 2008 X64 Terminal Server mode. (all users log to the Terminal Server to open their FE)

It has been a half year since we migrated to Server 2008 R2 x64, and while at testing all looked working well, I am slowly getting more and more complains from users, that since the upgrade to the new server (production was run under Windows Server 2003 up until then), performance has been hit.

I have found out that only in specific forms the performance is bad (or bad enough for the user to notice the difference).

It looks as when access requeires a form or a combobox recordsource, it can hang, freeze, even get a white screen NOT RESPONDING.

Sometimes it happens for seconds, sometimes even up to a minute until the data is requeired and the form is available to work on.

Since this happens on specific forms, i was trying to find out what is similiar in those forms that might be causing this issue. A guess of mine, is the use of ComboBoxes on those forms.. although its a wild guess, as i have more forms with comboboxes that work fine, and i cannot be 100% this does not happen on forms without combobox .

What i do know, is on an x32 OS (win 2003, win 7 x32), this does not happen, and performance is great.

My guess is something with ms access 2003 data retrival, or with the JET 4 engine, on x64 OS's is causing causes performance to steeply go down. It is not consistant, as i can then requery the form or data on it, and performance will be just fine. Lets say that if i put a requery button on one of my problem forms, every 5-10 clicks on the button, will suddenly cause this SLOW down, freeze.

I have looked all around , i am using ALL latest hotfixes and SP's, and checked this issues on multipule os's , and am not sure what to do next.

We are already deeply using Server 2008 r2 , that the last thing i would want to do is migrate to an x32 OS. we are also using Terminal Server Remote App's for some of our users, and I enjoy all the features that come with 2008 R2 (which is only X64 edition).

Has anyone else had performance and freeze issues with ms access 2003 or jet engine 4 on X64 machines??

Can anyone help me guess what causes this, and what i can do to fix this issue?

I have to say that our Server 2008 R2 machine which hosts the MDB's and users, byitself is a VM sitting on another Server 2008 R2 host machine, if that makes any difference.

Does anyone know if specific controls , recordsets or actions on a form trigger this? i will modify these problem forms, if I knew what was causing this issue.

Thank you in advance, and I will keep you posted if I figure something out. For now I have around 10 users who use this form daily, and ask me already when we will downgrade back to our 2003 server :(

Eli

Hi Again,

No one has issues like described above with access 2003 on x64 machine?

anyone?

Hi Eli,

Unfortunately, I don’t know of one specific thing that would cause this.  For the most part, your database application should behave the same way on a Windows 2008 x64 server as it did on a Windows 2003 x86 server.  A few questions I have are:

• If you move the file out of the VM environment and into a file share directly on the Windows 2008 server, do you notice the same behavior?

• Do each of your users have their own frontend or are they all using the same frontened database?  If they are all using the same frontend database, do you experience the problem if they use their own frontend copy of the database?

• Is this server on a local area or wide area network? 

• How many records are the comboboxes on your form bringing back?  If they are returning thousands of records, you may want to consider reducing the number of selections in these comboboxes, since this can definitely cause performance issues.

• Have you tried running a compact and repair on the frontend and backend database files?

• Do the NIC cards on the server have the latest drivers? 

• Are all of you users using the exact same version of Access and does this version of Access have the latest service packs installed?

• As a test, do you have a different Windows 2008 server you could try hosting the database files on?

Best Regards,
Nathan Ost
Microsoft Online Community Support

I am working with a customer were we have upgrade their servers.  They are current having the identical problem where access will lock up and disconnect them from the database.  We are using HP Thin Clients connecting to a new Windows 2008 R2 Server.

I have confirmed that all the drivers are current.  All the updates on this server.

Log Name:      Application
Source:        Application Error
Date:          11/5/2010 11:28:11 AM
Event ID:      1000
Task Category: (100)
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      SanitaryTermSrv.sanequip2010.local
Description:
Faulting application name: MSACCESS.EXE, version: 11.0.8166.0, time stamp: 0x46437912
Faulting module name: soa.dll, version: 11.0.8166.0, time stamp: 0x464374f6
Exception code: 0xc0000005
Fault offset: 0x000398f7
Faulting process id: 0x1434
Faulting application start time: 0x01cb7cf9c459db64
Faulting application path: C:\Program Files (x86)\Microsoft Office\OFFICE11\MSACCESS.EXE
Faulting module path: C:\Program Files (x86)\Microsoft Office\OFFICE11\soa.dll
Report Id: 4c323ce2-e8f1-11df-8cd7-0026b9487a6d
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="Application Error" />
    <EventID Qualifiers="0">1000</EventID>
    <Level>2</Level>
    <Task>100</Task>
    <Keywords>0x80000000000000</Keywords>
    <TimeCreated SystemTime="2010-11-05T15:28:11.000000000Z" />
    <EventRecordID>141359</EventRecordID>
    <Channel>Application</Channel>
    <Computer>SanitaryTermSrv.sanequip2010.local</Computer>
    <Security />
  </System>
  <EventData>
    <Data>MSACCESS.EXE</Data>
    <Data>11.0.8166.0</Data>
    <Data>46437912</Data>
    <Data>soa.dll</Data>
    <Data>11.0.8166.0</Data>
    <Data>464374f6</Data>
    <Data>c0000005</Data>
    <Data>000398f7</Data>
    <Data>1434</Data>
    <Data>01cb7cf9c459db64</Data>
    <Data>C:\Program Files (x86)\Microsoft Office\OFFICE11\MSACCESS.EXE</Data>
    <Data>C:\Program Files (x86)\Microsoft Office\OFFICE11\soa.dll</Data>
    <Data>4c323ce2-e8f1-11df-8cd7-0026b9487a6d</Data>
  </EventData>
</Event>

We had been using the same database on a server 2003 with the same thin client and we did not have this issue.

Thanks

Charles

we have the same problem, hang, freeze and white screen....

please please can anybody solve the problem?

thanks

Hello Nathan

I am sorry for such a late reply, but I had the feeling this is being caused by something on my individual machine, and started tweeking and playing around my server trying to solve it.

The time went by, and unfortunately my problem is not yet resolved :(

First I will answer your questions, and then point out more of my guesses to this issue.

* I also experince these issues on a local development machine of mine using Win7 x64 (non VM). I do not have these issues at all on machines using x32 OS's.

*The server is a terminal server 2008 r2 x64. All users (around 30) connect to this machine using remote desktop, and work on their own frontend. the back end's sit on the same machine, in a folder mapped as Y drive (for easy links from the Front Ends). So every user has his own front end, sitting on the same machine is the Back Ends.

* I have set a global date filter, which makes sure all recordsets on the form , its subforms and its comboboxes bring only few hundreds records, and again, these hangs and freezes do not happen at all on x32 machines with same amount of data.

* I run compact and repair, nightly on the back ends, i have compiled / decompiled , comact and repaired my front ends multipule times when trying to solve this issues. I also recreated the forms which caused the problems, believing maybe they were corrupted.

*NIC are up to date, but since all databases are sitting on the same machine, this should not be an issue. (maybe since my backend folder is a mapped drive , of a folder sitting on the same machine, this is an issue? ).

*all users remote desktop to the server, meaning they all use same access version. Our access is up to date with all updates. 

* we have an exect image of our main server running on our backup machine, and I used that for testing, with same results.

These issues keep showing up daily for the users using those front ends and forms. I also want to mention, these forms that cause this issue,  include "conditional formatting" (some configured through vba code ), and sub forms. They are rich with data on the screen, but again not thousands of records. They are forms in Continous mode. And mostly the freeze will happen when I move to another record , or do a requery to the form.

I have checked and rechecked my OnCurrent code and queires , to very there is not problem there, and cannot find anything.

When running the queires themselves of the form / subform / comboboxes , they run fast, and show results instantly. The OnCurrent code, does not have anything that should slow down or hang, and most important :

This issue happens randomly. I can do the same action, or move to/from a record on the form 10 times with no issues, and then the 11th time it will hang/ freeze / white screen. If i am patient enough, it will come back alive , sometimes after 2 seconds ,and sometimes after 20 :(

I am guessing that the connection with the back end is disconnected, not opened delayed or locked. I will mention that i have a recordset open to an empty table on the back end, which should keep connection with backend open at all times.

This happens also on my local development machine, when i am the only user connected to the back ends, so its not record locking of any sort.

I am still clueless and cannot help the people here yet with a solution. Our users continue to experince these delays at the moment, because we cannot downgrade to server 2003.

I am also wondering, if we upgrade our databases and access to 2010, will this issue be solved??

An upgrade like that is a project that will take us half a year, but if I can be certain it will solve this issue, we go ahead and start working on it. Its been half a year already for me trying to solve this issue, with no success.

thanks again for everyone, and i will keep you updated, if something comes up.

Eli

hi CityRock (and others)...

I'm monitoring daily this thread because I still have the problem.

Scenario with the problem:

Server with Windows Server 2008 R2 64 bit

About 10 client connectiong to server through Remote Desktop

Back End: Database SQL Server 2008 Standard

Front End: application written and running with MS ACCESS 2003, it uses linked tables (ODBC)

All users logs to the Terminal Server to open their FE

For my biggest customer I've solved reinstalling the O.S. on server (Windows Server 2008 64 bit in place of Windows Server 2008 R2 64 bit); so I can tell that the problem is only with R2 version!!

Obviously, I can't force all my customers to reinstall O.S, I hope something will find a solution ...

thanks

Hi CityRock and Loris,

As mentioned before, your database application should behave the same way on a Windows 2008 R2 X 64 servers.  Since you have been experiencing this issue for some time now, I think your best option would probably be to open up a support ticket so that someone from the Access team and / or Windows team can look into the issue with you.

http://support.microsoft.com/default.aspx?id=fh;en-us;offerprophone

Best Regards,

Nathan Ost

Microsoft Online Community Support

Hello Nathan,

we have the same problem with access 2003 running on Server 2008 R2.

The programm hang, freeze and white screen....

The problem occurred, when execute a query in a VBA module.

please please can anybody solve the problem?

thanks

Thomas

Hi,

I have fixed the problem.

I have changed the recordset from DAO to ADODB and it runs. 

So I thing it depends on the dao360.dll.

best regards

Thomas

my application have hundred and hundred of modules, forms and reports;

switching to ADODB is unthinkable!!

Since in Windows Server 2008 (non R2) there is no troubles,

I've tried getting JET DLLs (dao360.dll, msjet40.dll, msjint40.dll ecc.) from a Windows Server 2008...

now freeze and blank screen are less frequent but non completely removed.

In my case it was not necessary to change all recordsets to ADODB.

I had the problem always at the same line of code. So I changed the Code only at this function.

Try it out.

But in the end it is a bug that should fix microsoft.

Best regards Thomas

Hi guys, here another one with the same problem.

I have the same app in a win 2003, 2009 and 2008 r2.

I did not  own the application so I can't change the code.

I think replace files fron the 2008 to the 2006 R2 seems to be a good workaround.

Which files shoul be replaced?

Another hint or tip to solve this issue until a MS patch?

Thanks a lot.

Here the list of dll I replaced:

in C:\windows\SysWOW64

msjetoledb40.dll
msjint40.dll
msjter40.dll
msjtes40.dll
msltus40.dll
mspbde40.dll
msrd2x40.dll
msrd3x40.dll
msrepl40.dll
mstext40.dll
mswdat10.dll
mswstr10.dll
msxbde40.dll

hi loris corazza,

I have the same problem with server 2008 R2 and I´m at the point to reinstalling the O.S. on my server.

You say, that there is no problem on server 2008 Standard, 64 bit. Can you confirm this?

Best regards

Yes, I confirm....

with 2008 Standard 64 bit there is no problem.

Bye

Hi There,

I just popped back to see if anyone has more details or options to try out??

I do not have the patience to contact microsoft about this, anyone on this thread had any progress with this problem??

I am still effected by this issue.

Thank you

Eli

Hi Eli,

I´m getting the same issue!!!
Bad time when i decided to update my OS from Server 2003 to 2008 R2.

If you got ANY workaround about this issue please alert me!!!!
Have u already post this issue at Microsoft Connect website? I dindt find any post related this subject there. If u give the url i can try to vote the post, it will may "force" them to fix it faster.

Thank you!

Hi Rubens

I did not contact microsoft about this issue.

I tried going to their support website, and found myself looping and looping trying to submit a request. The only way i found to do it was paying their customer support help line...which I am not inteded to do, as it is their bug, and dont see a resdon to pay support for a bug in their product.

I did not even know about the Microsoft Connect website until you mentioned it, and went to it today. Again ,there are alot of agreements and documents and steps to do. I do not have the time or paitence to work it all out. I have to say that this is the first issue i had in the last 10 years where i could not find a solution or workaround on the internet myself, and i have never contacted microsft directly for support.

If you are willing to open a case with this issue with microsoft connect, please go ahead and I will vote for your post :)

If anyone else is willing to open a support case with microsoft please let me know , i will vote and do the best I can to help regarding this matter ,but at the moment I do not have the time and patience to contact microsoft myself.

I am still looking for workarounds, and doing my best to simplfy and make less complicated forms on my side, as this issue really happens on heavy data forms, usually involving subform, dropdown boxes and conditional formatting.

As always keep me updated if you find anything, i will do the same.

Thanks again

Eli

Hi there!

I have a same problem on Access 2003 on WS2008R2.

How do you think the replacement for Access 2010 will help solve the problem?

Too bad that a decision has still not found....

One more thing to note...which makes me wonder if the issue is more of a 'security' issue, or 'networking' issue... When we turned off the Windows Firewall (Start > Control Panel > Windows Firewall) it made everything lighting fast.  But then when i logged in tonight to move forward with it, it was slow again.  Maybe some of you could solve your issue by turning off (or tweaking your Windows Firewall).... 

Another reason I wonder about this is that we've found that linking back end tables on the C drive (or whichever 'local'/'physical' drive seems to make the 'connection' from the front end to the back end (MS Access) tables exponentially faster than to a 'mapped' drive--even on the same exact box...

Hi Steve and everyone else.

You got me thinking of a security issue, and i decided to go look at the event viewer once more.

I have found that everytime access freezes for me, the EVENT VIEWER SECURITY gives me the two events :

4624 + 4672

this is a service ADVAPI which uses NT AUTHORITY account domain to get access.

Now since these two events ONLY happen when ms access freezes, i want to believe ms access is the one requesting login, and might this might be causing the freeze. Its funny i would move between records with no problem on a form, and suddenly i would freeze. Go to the event viewer, and those two event logs show.

I found these two links talking about similar freezes with these event viewers, but no solution on them as well :

http://social.technet.microsoft.com/Forums/pl-PL/w7itproperf/thread/e9e0967f-cbda-406e-8bc8-236f62d0fd8b

http://answers.microsoft.com/en-us/windows/forum/windows_7-security/computer-hangs-microsoft-windows-security-auditing/8d8761ef-7937-4fda-9b8c-b864578ddec1

If anyone else can verify and check if these events show up to him when ms access freezes, we can confirm this to be the issue.

If anyone has any way to help let us know:)

thanks

eli

Finally I found a solution, at least it solve my problem...

Search at your regedit for
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Jet\4.0\Engines\Jet 4.0

Change the MaxBufferSize to 20480.
Not more than this because Jet nor support 64bits. If u use try to set 32768 some querys will stop work too!

Hope it helps,
Rubens Cury

• Proposed as answer by loris corazza Friday, March 25, 2011 10:34 AM
• Unproposed as answer by loris corazza Friday, March 25, 2011 10:36 AM

Finally I found a solution, at least it solve my problem...

Search at your regedit for
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Jet\4.0\Engines\Jet 4.0

Change the MaxBufferSize to 20480.
Not more than this because Jet nor support 64bits. If u use try to set 32768 some querys will stop work too!

Hope it helps,
Rubens Cury

• Proposed as answer by loris corazza Friday, March 25, 2011 10:34 AM
• Unproposed as answer by loris corazza Friday, March 25, 2011 10:36 AM

Finally I found a solution, at least it solve my problem...

Search at your regedit for
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Jet\4.0\Engines\Jet 4.0

Change the MaxBufferSize to 20480.
Not more than this because Jet nor support 64bits. If u use try to set 32768 some querys will stop work too!

Hope it helps,
Rubens Cury

I read the thread tonight because we just installed a Windows 2008 64 bit R2 server at a client where I am running a few Access databases that have up to now been running fine.  I am finding the same issues mentioned here.   I have a FE running locally on five computers.  There are combo boxes in the forms as well as sub forms that have have coded events.  The users have been reporting freezing issues while entering data especailly in the combo boxes.  It is pretting frustrating to see a database that you know should run fine not run well and not be able to do anything, so far, about it.  The BE which is on the new server is not very large in this case.  Many of the combo boxes are populated by data from local tables as i changed the design of the database to load all look-up tables locally when the FE is opened because of the issues encountered by users but they continue to have freezing problems.

We have also turned off the firewall on the server.   Beyond the locking and freezing I have observed a general slowness in all of the access databases since implementing this new server which has been quite dramatic.  Processes that took 10 minutes to complete are now taking 45 minutes.  I would like to keep this thread alive untill these issues are better understood since we are upgrading servers all the time and I have lots of access databases running at clients offices so I would like to see these problems addressed.  I am going to test security issues and if I come up with a solution I report it.  Thanks,

Bob Gouveia

I have a client that is seeing the same issue on 2008R2 remote desktop. Has anyone been successful in upgrading the runtime or Access on the server to Access 2010? If so, was the 32 or 64 bit used?

They are running Office Pro 2003 with the Office XP runtime for this application. I believe it was created with Access 2003 or XP.

• Proposed as answer by Steve Childs - OneSource Wednesday, April 06, 2011 3:54 PM
• Unproposed as answer by Steve Childs - OneSource Wednesday, April 06, 2011 3:54 PM
• Proposed as answer by Steve Childs - OneSource Wednesday, April 06, 2011 3:54 PM
• Unproposed as answer by Steve Childs - OneSource Wednesday, April 06, 2011 3:55 PM

I have a client that is seeing the same issue on 2008R2 remote desktop. Has anyone been successful in upgrading the runtime or Access on the server to Access 2010? If so, was the 32 or 64 bit used?

They are running Office Pro 2003 with the Office XP runtime for this application. I believe it was created with Access 2003 or XP.

• Proposed as answer by Steve Childs - OneSource Wednesday, April 06, 2011 3:54 PM
• Unproposed as answer by Steve Childs - OneSource Wednesday, April 06, 2011 3:54 PM
• Proposed as answer by Steve Childs - OneSource Wednesday, April 06, 2011 3:54 PM
• Unproposed as answer by Steve Childs - OneSource Wednesday, April 06, 2011 3:55 PM

Here's what we have found: Windows Server 2008 R2 causes Access 2003, 2007, and 2010 to hang, randomly, usually on combo boxes, (but in other places as well), for 15-180 seconds.  Opened case with Microsoft. They confirmed that this is a known bug with no resolution yet--in R2--because R2 is based on Windows 7.  (R1 is based on Vista).  

Our research has so far produced this resolution: Downgrading to Windows 2008 (original version) and then running Access 2007 or Access 2010 has given us positive results--no more hanging issues.  Our clients with Access 2003 still have hanging issues even on the original version.  You can request a free (except for shipping costs) Windows Server 2008 (downgrade) disk/media from microsoft by going here:

http://www.microsoft.com/windowsserver2008/en/us/downgrade-tc.aspx

Hope this saves some of you some of the hair i've had to pull out to get this knowle

Here's what we have found: Windows Server 2008 R2 causes Access 2003, 2007, and 2010 to hang, randomly, usually on combo boxes, (but in other places as well), for 15-180 seconds.  Opened case with Microsoft. They confirmed that this is a known bug with no resolution yet--in R2--because R2 is based on Windows 7.  (R1 is based on Vista).  

Is there an ETA on when it will be fixed?

I would prefer not to downgrade and then the fix is available soon after (thanks to Murphy). Not to mention the costs associated with rebuild, etc. These would be minimized if an in place downgrade can be done. Haven't tried that with 2008R2 to 2008R1, can it be done?

Based on the conversations that i had with Microsoft--the Office team, my gut tells me no time soon.  They've several open cases like it dating back 3-4 months.  I got the feeling that the issue is still in their department and has not yet been escaled up to the server department.

Can you downgrade? The only path we've found is to reinstall.  No simple 'downgrade' click, click you're done...  I've decided to move to what i know works, as the disc is almost free and it's only a few hours of time to get to a known solution.

We experience the Exact  matter here in our environment. Basically we moved  from 2003 to windows 2008R2 and the MSaccess2003 application that connectes to SQL is acting very strangely specially when it comes to displaying reports of the retreived data.

when running a query Access does nothing for some time and after some time (random time sometimes 30 seconds sometimes one minute or even 3 minutes) it starts running the query.

each report or query behaves differently (and it was deffinetly better on windows 2003 server environmnet). Data gets retreived then MSACCESS does nothing for a while and then the report pops up after waiting for 2, 3 or sometimes 5 minutes.

we also try to downgarde to Windows 2008 (32bit) which didnt resolve our issue.

MICROSOFT HELLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPP

Okay.... Had the same issue.

The ultimate resoluton was to start MSAccess with realtime processor use.

start "ProgramName" /realtime "C:\Program Files (x86)\Microsoft Office\Office11\MSACCESS.EXE" "G:\Program Files\MyProgram\Database.mdb"

We used processmon from Sysinternals and were able to see that Access was not really hanging but rather just processing realllllly slooow.  So we tested by bumping the cpu priority up a notch at a time till we got to the program to respond.

Running at normal the query took several minutes, at High it took around 20-30 seconds, at Realtime it took only 1 second.  But if we looked at the CPU usage for MSAccess it runs at almost 0% during the normal priority and running at realtime it spikes to 20%-50% then drops back down.  With 10 people running all at Realtime priority it still runs around 2-5% avg.

Hope this helps others.

• Proposed as answer by Brian_applied Friday, April 22, 2011 12:31 PM

Okay.... Had the same issue.

The ultimate resoluton was to start MSAccess with realtime processor use.

start "ProgramName" /realtime "C:\Program Files (x86)\Microsoft Office\Office11\MSACCESS.EXE" "G:\Program Files\MyProgram\Database.mdb"

We used processmon from Sysinternals and were able to see that Access was not really hanging but rather just processing realllllly slooow.  So we tested by bumping the cpu priority up a notch at a time till we got to the program to respond.

Running at normal the query took several minutes, at High it took around 20-30 seconds, at Realtime it took only 1 second.  But if we looked at the CPU usage for MSAccess it runs at almost 0% during the normal priority and running at realtime it spikes to 20%-50% then drops back down.  With 10 people running all at Realtime priority it still runs around 2-5% avg.

Hope this helps others.

• Proposed as answer by Brian_applied Friday, April 22, 2011 12:31 PM

I just set it manually to test and that seems to have helped, no locking up, etc..

I am having an issue setting the /realtime option since we use the /runtime switch in our path. I was able to get it to run in high, but not realtime from a command line.

Any suggestions?

cmd.exe /c start /REALTIME "E:\Program Files (x86)\Microsoft Office\Office10\MSACCESS.EXE" /Runtime "f:\ourapp\ourapp.mde"
Invalid switch - "/Runtime".

UPDATE

What i did was wrap it all in a batch file, then compile to an exe using Batch_to_Exe found here:

http://download.cnet.com/Bat-To-Exe-Converter/3000-2069_4-10555897.html

then right click on the exe and set the properties to run as administrator for all users on the Compatibility Tab "Change Settings for All Users"

 UPDATE:  Ran all day yesterday with not one performance issue, very happy end users!!!!!

Found out yesterday that the developer of the software we were trying to get to work was given our resolution by a Microsoft engineer as a potential workaround/solution.  At least this verifies that MS believes it to be a viable solution.  Hope this helps

From: Tina XXX (FLXXXX) [mailto:tXXX@microsoft.com]
Sent: Thursday, April 21, 2011 2:35 PM
 To: Arthur XXXX Jr
 Subject: RE: [REG:110122971186XX2] PRO/Windows Svr 2008 Std R2 AL/access application not working on new serverArt,

 My apologizes for the influx of emails from me in your inbox, but we are investigating the following as a potential workaround/solution. Could you test starting MSAccess with realtime processor use -Start "ProgramName" /realtime "C:\Program Files (x86)\Microsoft Office\Office11\MSACCESS.EXE" "G:\Program Files\MyProgram\Database.mdb"

Thanks,

Tina

I am able to get the MSACCESS to run at REALTIME with a batch file. The problem is when I open the application for testing, another MSACCESS process opens up which is in Normal priority. I even included another command in the batch file to open the application and set MSACCESS to REALTIME together for testing, but same issue happened. How can I set all the MSACCESS to run at REALTIME when users open the application and created multiple MSACCESS processes?

The solution works great but how do I stop UAC from prompting for password from a user when ‘Run as Administrator’ privilege for ALL USERS is set on the EXE?

I have looked everywhere for a solution to the "UAC Prompting a user for admin pwd" and cannot find a solution other than turning UAC off.

Am I missing something?

With UAC on when a user runs the EXE they must enter a password for one of the accounts on the system that has admin rights!

The admin rights accounts are listed and if the pwd is given to a user for one of them...well goodbye security.

Realtime is *not* connected to Access. It is a "cmd.exe" option. Please read this thread over and over especially near the end where the 'solutions' are.

Back to UAC.

I don't undertstand why there is no talk of the UAC problems. Everyone must be having them - unless this is not the appropriate place.

It is impossible to 'Run as administrator' without giving users the admin pwd.

OK so maybe you are using the runas.exe but it only works for specific cases of access design eg where Outlook is not manipulated. Also every user's instance of Msaccess.exe is listed as 'Administrator' user under Processes tab in Task manager.

My app manipulates Outlook and it cannot open it programatically. And many more problems with Outlook.

I contacted Microsoft directly about this problem 3-4 months ago. In additional to downgrading to Window 2008 Server (the non R2 version) fixing the speed/hanging issues--which i can confirm works, I worked with a Microsoft rep over the months and she has just informed me that they have come out with a Hotfix for speed/hanging problem.  The KB article is posted below:

http://support.microsoft.com/kb/2553116

Note: She sent it directly to me, but you can 'request' it at the top of the article above (and can install it after installing Office 2010 Service Pack 1).  Since i have moved all of our customers back to the original version of Windows Server 2008 I have not been able to 'confirm' if it really does fix the 15-180 second hangs--but i am crossing my fingers that it will.  Hopefully someone out there can give it a try and see if it fixes your problem(s).

But this is not a solution for me...

Our application runs with Access 2003 (the last one with ODBCDirect) and we can't migrate to Access2007/2010 without a complete revolution!!!

MICROSOOOOOOOOOOOOOFT GIVE ME AN ANSWER !!!!!!!!

We are in the same situation.  We are stuck on Access 2003 since a lot of our code doesn't work in Access 2007+ without a lot of rewriting.  I was really hoping the fix Microsoft provided was for the Operating System, not Access.  We even have the same type of problem starting in Windows 2003R2.  It just happens less often and is less severe than in Windows 2008R2.  We are working around it in Windows 2003R2 by launching our Access app with single processor affinity, but that fix doesn't help in Windows 2008R2.  And the suggestion above to run in Realtime mode is NOT an option.  I can't have all our users running as administrators and at priority levels that will cripple the rest of the OS when a process uses lots of CPU.

The root cause of these slowdowns must be how Windows schedules the internal Access application threads.  Hopefully they come out with a generic fix or work around that works for everyone.

I notice that it's happend on a subform, the combobox on the out side form work well and on the inner form there is a problem.

We switched off ipv6 on the network card, and it helped on these issues.

Hey guys

I have the same issue, after a few clicks, the application hangs, then a few minutes later the application is responding again... The application is buyed erp software which is compiled, so I have no chance to change the source code. The application uses DAO.

any further ideas? tried following:

• switch off ipv6
• changed maxbuffersize in registry
• switch off DEP/UAC
• Start in Compatibility Mode XP/SP3 (Properties EXE)
• tried to start as admin
• MS KB2553116 installed
• C:\Program Files (x86)\Common Files\microsoft shared\DAO -> dao360.dll replaced

Thanks & Regards

Thomas

• Edited by thobil Thursday, January 05, 2012 9:52 AM

Hey guys

I have the same issue, after a few clicks, the application hangs, then a few minutes later the application is responding again... The application is buyed erp software which is compiled, so I have no chance to change the source code. The application uses DAO.

any further ideas? tried following:

• switch off ipv6
• changed maxbuffersize in registry
• switch off DEP/UAC
• Start in Compatibility Mode XP/SP3 (Properties EXE)
• tried to start as admin
• MS KB2553116 installed
• C:\Program Files (x86)\Common Files\microsoft shared\DAO -> dao360.dll replaced

Thanks & Regards

Thomas

• Edited by thobil Thursday, January 05, 2012 9:52 AM

Greetings Folks,

I just purchased Access 2010 to prepare for a client's requirements (it was about $180.00). I installed the software on Windows 2008 R2, which is only 64 bit. I installed the 32-bit version of Access 2010 after reading the rationale for this. I did not have Access 2007 on the machine before, but I did install Office 2007 (Excel, Word). Now, Access crashes on the Web Assets Template every time. It also never completes the Installation Wizard, and this runs every time. This, Gentlemen and Ladies, is what I call a plain old defect. We need a fix from Microsoft. Here is the error message that occurs when I run the Web Assets Template:

Problem signature:

Hi Everyone,

How sad it is to be here a year and half after posting the first thread just to see that microsoft confirms it has a bug, and confirm they will not provide a solution for it!

MICROSOFT I AM SORRY BUT I CANNOT CURRENTLY UPGRADE TO ACCESS 2010.

I need to rewrite huge amount of code and replace active x to do that.

Not to mention that half of my users use small screen netbooks,  forcing the ribbon in access 2010 takes so much screen space my forms will all become unusable.

MICROSOFT - by not fixing this bug, even more fixing it only for access 2010 version, you tell me that my last 10 years of work can go to hell.

If this is your way of forcing us to upgrade to 2010 than you are doing it all wrong.

I will not waste half a year rewritting code and adjusting forms for Access, as in 5 year this might happen all over again.

You are forcing me now to move away from Ms Access (maybe thats what you want...i dont really understand anymore).

But I will not look for an alternative within microsoft that i am sure of.

The funny thing is, I probably would have upgraded slowly to access 2010 within the next 2 years. In my pace, and after checking and verifying all code works correctly on 2010. But in this situation, my users cannot work right now, and although a fix exists Microsoft decided not to apply it on JET. So forcing me to upgrade to 2010 in a rush is no answer.

I am paying alot of money for the software, and for our 2008 r2 OS. I believe a bug like this ,caused to so many developers should be addressed by Microsoft. And telling us to upgrade to 2010 is not an anwers.

Microsoft allows Access 2003 to run on Server 2008 R2. Then it should allow it to run smoothly with no bugs. And if a bug is found, and is being addressed, it should be applied to all working versions of Access (Jet engine in this case).

I also believe Jet is part of Windows, and not of Access, so even if support for access 2003 has an excuse to why they should not fix it, Windows Server 2008 R2 should address this issue, as it is only happening on this version of OS.

So my next question to everyone here is what should i do next ?

My guts tell me to look for an alternative outside of microsoft alltogather. Are there any recommandations?

I have built an extended ERP program serving one company with about 50 users. I have been coding and building it with Access for more then 10 years now. If my users continue to complain much longer i will downgrade our server back to 2003, and by that i will slowly move out of microsoft altogather.Maybe my application is too big for Access anyways, although up till Server 2008 R2 performance was the best, and development was the easiest. But maybe its time to move on.

The second solution would move to Access 2010 and issue the hotfix that should solve the problem.

This will require me at least half a year of going over all code, activex and so on that i know from initial tests cause problems.

My biggest problem is the ribbon. IS THERE ANY WAY TO GET RID OF THE RIBBON altogather, and have my menubar on the left side of the screen? I have alot of forms built for specific screen resolution and dont have much space to play around with them. Having the ribbon requires me to change all these forms, and somehow get all the data in small height.

I am clueless, actually hurt and pissed of at microsoft. You have a HOTFIX For the problem, dont use it to make us upgrade your software. Use it to help your developers and customer solve bugs YOUR SOFTWARE has.

Put alittle more effort and time into it, and make the hotfix for JET as well. Then i will consider upgrading (in my pace) to 2010, not the other way around.

disappointed

Eli Gur

Eli there is no need to upgrade nor to rewrite anything. Please have a good read for the NON-2010 solution provided previously using BAT to EXE running in highest priority. It works well.

Then you will run into UAC problems for your users. These can be solved by purchasing a product from Beyondtrust.

http://www.beyondtrust.com/Products/PowerBroker-Desktops-Free-Tool/Evaluation/Thank-You/Default.aspx

Like you I have a very sophisticated database that has been developed over many years running in Access 2003.

BTW for those that are interested these problems first surfaced in WS2008 but only very slightly - remember the momentary 'white application window' and the '...not responding' in the top left hand corner of that window. WS2003 had no issues.

I spent quite a long time delaying non-essential DB access functions at the time of 'going to a new record' in order to speed things up under WS2008.

Ironically the huge problems Access faces in WS2008R2 meant I could implement the workaround AND restore my 'delayed non-essential DB access' functions.

I have worked with Access since it came out in 1992 and the people MS has working on/supporting Access now are totally inferior to those in say the first 10 years or so. The top people are long gone - the remnants are clueless AND without any corporate power - ie they can't force the OS developers to fix the problems. Don't get me started.

no thomasaj,

running access in highest priority does not solve the problem, application hangs and freeze (pheraps) less frequently but HANGS.

my English is very poor so I can not express how I wish, however, I fully agree with the last post of cityrock.

Take in mind......our msaccess application, developed since 1998, consists of about 2 million lines of source code,

Our new customers are forced to buy Windows server 2008 R2 and then downgrade to Windows Server 2008, it's disgusting!! 

Hm...seems we are dogs barking at shadows cast by MS.

Hey I have a solution. Pay someone else to bark at MS and then when they cannot fix the problem bark at them.

You don't get any better resolution but a heck of a lot more satisfaction (ish).

Anyway BAT to EXE plus *REALTIME PRIORITY* works great for me so for now I'll pass paying someone else to bark at.

.....pity

I notice no MS person has thrown his hat into this ring for a long time.

Yep. Seriously clueless people at MS now. Shareholders should be up in arms about paying wages to total incompetants.

Thomas,

Can you confirm I can run it in highest priority in a production server with 50 users running their own FE (bat file would be now) at the same time.

Can do harm in anyway?

Thanks

Eli

Run in *REALTIME PRIORITY*.

Absolutely positively no harm in any way.

Are you saying you have not tried this solution! Surely you can try it on your test FE/BE?

I repeat that you will come across UAC issues and you will need the product from Beyondtrust.

I notice no MS person has thrown his hat into this ring for a long time.

Yep. Seriously clueless people at MS now. Shareholders should be up in arms about paying wages to total incompetants.

@CityRock,

I have migrated an Access 2003 application FE/BE to Access 2007/2010 FE with SQL Server 2008R2 B/E running under Windows 7 Ultimate.

Your comment about being able to getting rid of the ribbon is doable my app still uses Command Buttons and Menus from Access 2003 and the Ribbon is not used or shown.

Instead of migrating the MDB to an ACCDB, I just ran the MDB as is within Access 2010. If Command buttons and menus are existing in the MDB, Access 2007/2010 will use them instead of the Ribbon.

We were having the same issue with an Access 2007 DB in Server 2008 R2. 

The issue is not that Access requires CPU priority in Realtime. The issue appears to be the way Server 2008 R2 sandboxes Access. I've watched CPU usage literally drop to idle while Access was trying to complete some pretty heavy tasks. 

I stumbled upon an interesting side effect -- if you toggle between priorities (doesn't matter which one), it "wakes" Access back up. You can test this by running your app, and when it gets stuck, toggle the CPU priority level and you'll see it jump back into action. 

Our solution is a script that will toggle priority between Above Normal and Normal every 15 seconds while Access is running. We've received reports that our DB is running faster than its ever have. 

• Edited by Windows_Drone Friday, July 27, 2012 6:58 PM
• Proposed as answer by Windows_Drone Friday, July 27, 2012 6:58 PM

We were having the same issue with an Access 2007 DB in Server 2008 R2. 

The issue is not that Access requires CPU priority in Realtime. The issue appears to be the way Server 2008 R2 sandboxes Access. I've watched CPU usage literally drop to idle while Access was trying to complete some pretty heavy tasks. 

I stumbled upon an interesting side effect -- if you toggle between priorities (doesn't matter which one), it "wakes" Access back up. You can test this by running your app, and when it gets stuck, toggle the CPU priority level and you'll see it jump back into action. 

Our solution is a script that will toggle priority between Above Normal and Normal every 15 seconds while Access is running. We've received reports that our DB is running faster than its ever have. 

• Edited by Windows_Drone Friday, July 27, 2012 6:58 PM
• Proposed as answer by Windows_Drone Friday, July 27, 2012 6:58 PM

I haven't read this blog in quite some time, but i can tell you that we solved all freezing problems by upgrading Access to Office or Access 2010 SP1 (when running on Windows 2008 Server R2).  We've never been able to find a fix for Access 2003 or 2007.

In some cases, with some of our customers, the 'solution' above has not been feasible, so Windows_Drone's solution above is very interesting.  Windows_Drone, can you share the 'script' code you used to change the priority of the Processor on the fly (automatically)? and what you did to make it execute every 15 seconds??  That sounds like you've come up with a pretty good work around solution..  Any additional info on this would be very appreciated.  Thank you.

I can't post the script, as it belongs to my company. I can say, that it's very easy to replicate.

Here's a great place to start: 

http://www.activexperts.com/activmonitor/windowsmanagement/adminscripts/processes/

I tried to read through all these posts, so might have missed, but here is my deal...

Access 2003 backend mdb's (5, some rather large)....on Server 2008 R2 standard.  The front ends are a mix of on local clients (xp, R3), and some users run front end from Server 2008 terminal server (also R2 standard).  Note approximately 200 total users, probably the mix 50-70 concurrently.

The users that have direct lan connection to backend server location, front end very slow (, and if you open linked tables natively via this front end as administrator, slow performance.

The weird (or maybe not), but the terminal server users, performance is faster.  Additionally they connect via a Cisco wireless connection! 

This was a recent conversion from server 2003 for both backend server and terminal server.  Both also physically older servers!

A consultant is in charge of this project, but so far no progress.   Unfortunately I have little admin access to either server at this point (company layered IT responsiblities).

Note I was able to test with a Win 7 32 bit client, same poor performance over direct lan.   My guess is that the Terminal server is faster due to being it and backend server 64bit

Any thoughts, suggestions appreciated!

Note the backend and frontend mdb's were originally Access 2000 file format, converted to 2002-2003 format prior to conversion.

I confirm that Windows Server 2012 solve the problem but it generates other:

- in some circumstance, it's difficult to resume a msaccess forms previously reduced to icon (you must click the icon, right click on it, then choose resume; a simple click on icon does nothing)

- msacces forms randomly desappears;  if the form is Modal..there is no way to proceed (you must press Alt-Tab twice to resume visibility),

• Proposed as answer by JayJay Rubin Friday, July 12, 2013 6:13 AM
• Unproposed as answer by JayJay Rubin Friday, July 12, 2013 6:13 AM

I installed Server 2012.

I installed the same Access 2003 app that was a disaster on 2008R2.

With limited testing it seemed to run fine.

I urge others to try same and post results.

Tom

I confirm that Windows Server 2012 solve the problem but it generates other:

- in some circumstance, it's difficult to resume a msaccess forms previously reduced to icon (you must click the icon, right click on it, then choose resume; a simple click on icon does nothing)

- msacces forms randomly desappears;  if the form is Modal..there is no way to proceed (you must press Alt-Tab twice to resume visibility),

• Proposed as answer by JayJay Rubin Friday, July 12, 2013 6:13 AM
• Unproposed as answer by JayJay Rubin Friday, July 12, 2013 6:13 AM

The question wether the front end, back end and MDW files are on the terminal server or on a seperate (virtual or physical) file server, haven't been discussed.

I have a customer who has recently upgraded from windows server 2003 to 2008 r2 and now the intermitent hangs start to be reported. In this scenario, all files are on the terminal server.

I have another customer who is using the same software, about a year now since the upgrade to 2008 r2, no reports of intermitent hangs. In this scenario, all Access files are on a seperate virtual file server (sbs 2011).

In both scenarios there are some users who use the software localy (LAN) (more so on the 2nd scenario).

I also recall once having problems on terminal server 2003 with a different application - on Access 97 (still running).

In that case, there also was a file server and the terminal server was added to it for remote users.

But only when I moved the MDW file from the TS local c drive to the file server (same folder where the Back End was) the problem was solved. Since it was many years ago, I don't exactly recall if the problems where intermitent hangs like the ones discussed here, but it was somethings of the sorts.

Please confirm or disconfirm if putting the Front End files, Back End and MDW on a seperate file server solves the problem

I can't post the script, as it belongs to my company. I can say, that it's very easy to replicate.

Here's a great place to start: 

http://www.activexperts.com/activmonitor/windowsmanagement/adminscripts/processes/

Hi, still the same problem with ms access 2003 DAO db and windows 2008 r2 or windows 2012r2 Remote desktop .

Is anyone has tried this workaround or could help me putting it in place ?

Any other clue about this issue ?

Regards,

Fred

We were having very similar problems to what has been posted. I have found something that seems to be working for us.

Front end is Microsoft Access 2010, client OS is 32 bit Win7.  Back end is Server 2012 64 bit, database is SQL 2008 R2 (with SSD drives).  We use ODBC and linked tables in the Access app.  The client's server was upgraded from 32 bit Server 2003.  After upgrading to the new server the Access program would freeze and we would even get Login Time Out messages, seemingly randomly.  Do I need to describe the clients reaction to this after installing a screaming fast server?  Very frustrating.

Our solution is simple and although it has been less than a day the spinner, the freeze, and the Login Time Out messages have not appeared.  Before all would show up consistently and within short intervals.

On the SQL Native Client I simply changed the Server from the server name to its IP address.  I'm talking about the bottom drop down on the first page of the configuration.  I know that you can do tcp:<servername> but this is working and I'm not going to argue.  Sometimes getting the ODBC right seems like a bunch of voodoo to me.  Hope this helps others.

We were having very similar problems to what has been posted. I have found something that seems to be working for us.

Front end is Microsoft Access 2010, client OS is 32 bit Win7.  Back end is Server 2012 64 bit, database is SQL 2008 R2 (with SSD drives).  We use ODBC and linked tables in the Access app.  The client's server was upgraded from 32 bit Server 2003.  After upgrading to the new server the Access program would freeze and we would even get Login Time Out messages, seemingly randomly.  Do I need to describe the clients reaction to this after installing a screaming fast server?  Very frustrating.

Our solution is simple and although it has been less than a day the spinner, the freeze, and the Login Time Out messages have not appeared.  Before all would show up consistently and within short intervals.

On the SQL Native Client I simply changed the Server from the server name to its IP address.  I'm talking about the bottom drop down on the first page of the configuration.  I know that you can do tcp:<servername> but this is working and I'm not going to argue.  Sometimes getting the ODBC right seems like a bunch of voodoo to me.  Hope this helps others.

Edit 2/3/2015 - This has worked on a second machine.  Based on that I'm going to propose this as an answer.

• Edited by Jefph Tuesday, February 03, 2015 5:22 PM
• Proposed as answer by Jefph Tuesday, February 03, 2015 5:23 PM

We were having very similar problems to what has been posted. I have found something that seems to be working for us.

Front end is Microsoft Access 2010, client OS is 32 bit Win7.  Back end is Server 2012 64 bit, database is SQL 2008 R2 (with SSD drives).  We use ODBC and linked tables in the Access app.  The client's server was upgraded from 32 bit Server 2003.  After upgrading to the new server the Access program would freeze and we would even get Login Time Out messages, seemingly randomly.  Do I need to describe the clients reaction to this after installing a screaming fast server?  Very frustrating.

Our solution is simple and although it has been less than a day the spinner, the freeze, and the Login Time Out messages have not appeared.  Before all would show up consistently and within short intervals.

On the SQL Native Client I simply changed the Server from the server name to its IP address.  I'm talking about the bottom drop down on the first page of the configuration.  I know that you can do tcp:<servername> but this is working and I'm not going to argue.  Sometimes getting the ODBC right seems like a bunch of voodoo to me.  Hope this helps others.

Edit 2/3/2015 - This has worked on a second machine.  Based on that I'm going to propose this as an answer.

• Edited by Jefph Tuesday, February 03, 2015 5:22 PM
• Proposed as answer by Jefph Tuesday, February 03, 2015 5:23 PM

Now that Windows 2003 is no longer supported we were forced to moved to a newer OS. We ended up on 2008R2 64 bit like we had tried unsuccessfully years ago. We also got our app moved to Access 2007 but even with the latest Access updates, we still suffered from the same old slow query problem with just a small handful of databases. A query that normally takes a second or two randomly takes 1-3 minutes. During that time no CPU is used and we only see about 10 MDB reads/sec (instead of thousands/sec when it runs normally).

We finally worked around the problem by doing the following in our RDP environment:

1. Changed our GPO to give users the SeIncreaseBasePriorityPrivilege permission so they don't have to be administrators in order to change a process to REALTIME priority.
2. Launch our MSACCESS based app with the REALTIME process priority. We used a custom EXE we already had to do this. Using a CMD file to call START /REALTIME ... probably would work as well.

We think the above will only be practicle on Windows 2008R2 or above because of CPU Fair Share scheduling. Even if a bunch of processes in different RDP sessions use a ton of REALTIME CPU, Windows still gives out CPU cycles to normal priority processes in other sessions so other users can still login and access the start menus, etc.... 

The above fixed our slow query problem in Access 2007. Once we saw that we tried the same with Access 2003 which also worked. We switched back to Access 2003 again since it is so much more reliable. That eliminates lots of random errors, crashes and odd behaviors that only occurred in Access 2007. 

Mike I cannot thank you enough for your post.

"Changed our GPO to give users the SeIncreaseBasePriorityPrivilege permission so they don't have to be administrators in order to change a process to REALTIME priority." works perfectly!

I have had my users as Administrators for 4 years now.

To have the decency and wherewithal to bother to post a solution after all this time is incredible. And soooooo simple! You are a hero! Seriously.