MS Access 2010 - Slow on 64 BIt Terminal Server?

Question

Hi,

We have an MS Access 2010 application that suffers from performance problems when running on a Windows 2008 R2 64 Bit Terminal Server.

It is a 32 bit application, that uses ADO / DAO / ODBC to connect to a SQL Server Database. When the application runs on a 32 bit Windows 7 PC we get good response times (1-2 seconds) to load a form with data.

In the TS environment, it takes 8 seconds to load the same form / data. We have even stripped out all of the code (including data access) and left the Form controls, Tabs and sub-forms and this takes a few seconds to load on its own. (Some of the sub-forms contain icons for a Toolbar.)

Just wondering if anyone has had the same problem?

Does Access 2010 have problems with the number of controls on a form?

Many Thanks

Paul

Answer 1

I'm running 32-bit Access 2010 on 64-bit Windows 7 Enterprise and I am not seeing this slow-down. But then I'm not using TS. Maybe someone who is using it can chime in.

---

Bill Mosca
www.thatlldoit.com
http://tech.groups.yahoo.com/group/MS_Access_Professionals

Answer 2

Hi tr3fella,

According to your description, you could refer to below links to check whether they are help you fix your issue:

https://social.technet.microsoft.com/Forums/office/en-US/3aac9bc7-51db-4ff6-b8c5-e85faaae6b38/ms-access-2003-on-server-2008-r2-x64?forum=officeitproprevious

http://answers.microsoft.com/en-us/msoffice/forum/msoffice_access-mso_other/access-database-very-slow-on-windows-server-2008/f3239ee4-d204-4e2d-a923-8c2a93c7dcea

Thanks for your understanding.

Answer 3

Thanks Bill - I will try on Windows 7 64 bit to see if I get the same problem

Answer 4

Thanks David, I will try some of the suggestions in the articles

Answer 5

Where is the SQL Server located in relation to the TS and workstation?
Is the network speed the same for all? I ask because I once had an issue with that. New server connected at 100mbps when old one was 1gbps. After many exchanges with IT, turns out the new server got plugged into a different switch. Reconnected and got the 1gbps.

Answer 6

The TS & SQL Server are on the same VM in the same data centre so hopefully networking shouldn't be an issue.

Many thanks for your suggestion though

Answer 7

That is indeed strange.

If you logon to the server console as one of those TS users and launch the application, how well does it run?

In above you are thus logging on to the server, and as you note no network is between the user instance and that of SQL server.

Something else is at wrong here.

Are you using a domain controller, or is the connection from Access using SQL logons?

I would think that if using windows authentication for the SQL instance, and the auth server is NOT on the same box, then that could well be the issue. However, if you saying that other workstations (non TS) work fine when connecting to that same instance of SQL server, then clearly windows auth or the SQL server is not the issue.

And given that when running TS users there is NO network between the SQL server and the user, then this again indeed makes little sense.

There is something missing and very wrong here. (but we just not sure what).

A few things:

Are you using a compiled accDE as compared to a accDB for these TS users? Does each user on the TS box have their OWN folder on that TS box which has the accDE front end? (so each TS user gets their own compiled accDE front end in a folder on that TS box). In other words, you not allowing multiple users into the SAME copy of the front end, right?

Regards,

Albert D. Kallal (Access MVP)

Edmonton, Alberta Canada

Answer 8

Hi Albert, just to answer your queries.

We are running ACCDRs and each user has their own folder / copy, stored on the C: drive of the terminal server.

Yes, our client is using a Domain Controller and we are using Windows Authentication to connect to the SQL Server Database.

However, to eliminate VM and the Domain Controller, I have built a new Windows 2008 R2 64 Bit Server with Office 2010 Professional installed (32 Bit). The new server is not part of a domain and Terminal Services has not been installed. The SQL Server (2008 R2) is physically next to the new server.

Running the software (ACCDRs) on the new Server is still much slower than on a 32 bit Windows 7 PC.

Interestingly the PC & Server are the same spec (Processor, RAM etc). On the Windows 7 32 Bit PC, a form takes 2 seconds to open, compared with 4-6 seconds on the Windows 2008 R2 64 Bit Server!

I have also tried using a SQL server Login to connect to the SQL database, and I get the same results.

Any ideas please?

Answer 9

Surprising that you are running win7 x32 (it is quite rare and very few vendors and machines have win7 x32).

However, win7 x32 or win7 x64 really should not make any difference here.

And you state you are running accDR’s, but are those an accDE, or accDB renamed as “r”. You want to try compiled accDE’s here). So not all accDR’s are the same. So is that accDR a compiled accDE?

As you note, we assume then that each user on the TS box has their own copy of the accDE in a personal folder (so multiple users are not launching the SAME copy of the front end application, but each user has their own front end, and that is an accDE – not an accDB renamed as an accDR).

I would consider re-linking the tables using the SQL native client 10 to see if that helps.

And if you have any virus software such as Symantec endpoint etc. on the server, test with those disabled.

You also mention that the win7 x32 runs faster, is it connecting to the same instance of SQL server, or a different version or instance of SQL server?

To be fair, the server by default does run “GUI” applications slower and with less prieroty – but when using TS, then this tends to less of a issue  due to process scheduling etc.

So just a clean windows 2008 server box will in general run office applications slower – because a server is setup to give more power to non interactive applicatons (like SQL server, and networking services etc.).

So I don’t believe this is a x32 vs x64 bit issue, but that of some other settings that is elusive. If the application NEVER ran that fast on any server setup, then it might just be the fact of how the server OS gives "low" priority to GUI (interactive) applications. You could try for a test changing the priority:

Eg:

http://www.wikihow.com/Change-Process-Priorities-in-Windows-Task-Manager

Last, but not least: do forms attached to "small" tables and datasets load slow, or just forms attached to larger tables? You might want to optimize the amounts of data you are pulling into to forms. I explain this concept here:

http://www.kallal.ca/Search/index.html

Regards,

Albert D. Kallal (Access MVP)

Edmonton, Alberta Canada