32 bit Access Databases Slow Startup On 64 bit Windows Server (1 Viewer)

[yaya]

Hello,

I have recently moved an old .mdb database over onto a new 64 bit 2012 Windows Server from a 32 bit Windows Server Standard (2007).

I've noticed that the database takes about 30 seconds to open where before it would open almost instantly.

After googling around I've tried messing with the registry buffer size but didn't even see the key in regedit to change.

I've also tried switching advanced system performance settings from "adjust for best performance of background services" to "adjust for best performance of programs" but this hasn't helped at all.

Could the reason for this issue simply be because its 32 bit access running on a 64 bit machine? Is there any way to speed up the start/run time of it?

Kind regards

 

[theDBguy]

Hi. What exactly does your database do during startup? If you're running any code, would the speed at startup change if you temporarily disable those code?

 

[yaya]

I have tried opening the database normally and opening while holding shift down. Regardless it takes around 30 seconds. This happens for any database I try to open.

 

[theDBguy]

I have tried opening the database normally and opening while holding shift down. Regardless it takes around 30 seconds. This happens for any database I try to open.

How about creating a new blank database on the server itself and then opening it? If it's still slow, then I guess we'll have to figure out something about the server rather than the database.

 

[yaya]

How about creating a new blank database on the server itself and then opening it? If it's still slow, then I guess we'll have to figure out something about the server rather than the database.

I just tried with a blank database and the same thing happens.

 

[theDBguy]

I just tried with a blank database and the same thing happens.

Does it also happen with other programs like opening an Excel spreadsheet or a PowerPoint slide? You may have to get the IT guys involved if it has something to do with the server configuration.

 

[The_Doc_Man]

When you are running on a 64-bit system using 32-bit software, you might be running into an issue with the SVCHOST.EXE "shell" that is used to run 32-bit apps of any kind, but to be honest, I would be surprised if that were the problem. See, any old utilities like FILECOPY and DELETE use the O/S's file system as 32-bit apps and were not upgraded for 64-bit code. They ALSO use that shell and if it were SVCHOST killing you, it would kill other utilities too. A LOT of them.

The only other things that would make it run slower or faster would be if you didn't have enough virtual memory backing store, i.e. the size of the SWAP file, or some kind of scan running at startup. Is there an anti-virus program running on this server?

A test that might be useful would be to launch the task manager in a window and tell it to show you processes from all users. Click the CPU Time column (might have to click twice) so that you see processes sorted by descending amounts of CPU usage. On a not-too-busy system, the "System IDLE" Process will be the top CPU time eater, so you can tell when you have it right. Now launch Access windowed rather than full-screen. Per your described symptoms, you have 30 seconds to see what is running before your launch succeeds.

If that test fails to show anything, repeat the procedure but click on the Task Manager's I/O column to show you what process is performing I/O (and how much). There is also a column for page faults. You can repeat the experiment with various factors to see what is going on. You can click in the header of Task Manager to customize what metrics it will report. There is also the option to run the performance monitor to get an idea of specific processes that are eating your system for you.

Basically, there is no hardware difference and not that many driver differences between a server and a home or professional version of Windows. They all use more or less the same device drivers and would also use the HAL specific to the box you are using. The task scheduler is the same, too. Most of the separate utilities run at startup are the same, too, because they didn't need 64-bit. The MAIN difference between various versions of Windows is found in registry settings. Not ALL of the differences are in the registry - but a lot of them are just settings. Therefore, when an app slows down on a server, it isn't usually either hardware or physical resources. But it might be quotas, swap file, or an a/v scan that runs on the launch of software that hasn't been added to the "trusted" list for that anti-viral package.

 

[yaya]

You may have to get the IT guys involved if it has something to do with the server configuration.

I am one of the IT guys -_-

BUT WE FINALLY FIGURED IT OUT!!!

It turns out that on start up, Access was trying (and failing) to connect to the internet and call home. The proxy settings weren't set up on the server yet and so we opened IE and turned on our auto script. Doing this solved our issue and now the database opens instantly again.

Thank you both for your time and responses with this issue.

 

[theDBguy]

I am one of the IT guys -_-

BUT WE FINALLY FIGURED IT OUT!!!

It turns out that on start up, Access was trying (and failing) to connect to the internet and call home. The proxy settings weren't set up on the server yet and so we opened IE and turned on our auto script. Doing this solved our issue and now the database opens instantly again.

Thank you both for your time and responses with this issue.

Hi. Congratulations! Glad to hear you got it sorted out. Good luck with your project.

 

[The_Doc_Man]

Ah, that would explain the 30 seconds. That is almost a universal default for network timeouts (if you haven't tried to tune the timeouts for your local situation.)

But why would it call home? Were you using Office 365 on the server? I don't recall that any of the Office versions installed from a CD or DVD need to "call home" on startup.