Shell function slow response whne PC is connected to router

[RodShinall]

A command button on my form runs the Shell function to open a PDF viewer which displays the PDF file associated with the current record.

Dim strClickScan As String
strClickScan = Shell("C:\Program Files\SumatraPDF\SumatraPDF.exe ""D:\Periodical Reference Index\" & txtRecordID.Value & ".pdf""", vbNormalFocus)

Until recently Sumatra opened and displayed the PDF instantly. Now, however, there is a delay of several seconds with a Not Responding message before the program starts and displays the file. This happens when Shell runs other programs as well. But here's the strange thing; this delay occurs only when my PC is connected to my router (I am not online at the time). When I disconnect the problem does not occur and it does not occur outside of Access. As I have noticed this only for the last few weeks and my feeling is that this has something to do with a Microsoft update and possibly security related. This is very annoying. Any help would be greatly appreciated.

 

[isladogs]

i've never used or even heard of Sumatra before and don't know whether a Windows/Office update could be the issue.
Suggest you try using a different PDF viewer as a test. For example try using the Edge browser.

If that doesn't help you could try rolling back recent updates and/or report the issue to MS via the user feedback process.
Good luck

 

[RodShinall]

Thank you for your reply. Sumatra is a light weight PDF reader that I have used for quite a while. It doesn't have the bloat of some others and pops up instantly outside of Access. This issue is specifically to do with Access. I'll try reporting the issue to MS.

 

[isladogs]

OK but i expect they will also ask you to rry using anither PDF reader such as Edge.
Suggest you do so before reporting the issue.

 

[Isaac]

Maybe something to do with the effort it takes the computer to evaluate whatever D:\ is

 

[The_Doc_Man]

Although it might be tricky to prove it, I would consider that the fact of having that external connection to the router is a major factor. Next time you have the chance to try this, set up a watch with a second hand and see if that delay is exactly 30 seconds.

If it is, your problem is that the computer is checking the network for something and is experiencing a timeout. You might need to read up a bit on the TRACEROUTE command (available through the CMD window from an administrator account). It would tell you what you are touching. The other possibility is to get to CONTROL PANEL >> ADMINISTRATIVE TOOLS >> EVENT VIEWER. Perform your experiment and note the exact time to the second when you start. If you have a "clock gadget" on your desktop, that clock comes from the system clock so any system logs will match that time if you are observant. I would expect to see a network timeout in one of the event logs. Since these logs are sorted chronologically, it should be trivial to find the right entry in one of the several logs you can see from the Event Viewer utility.

In case you were wondering, 30 seconds is the default network timeout for an attempt to connect to something on some other part of the network. Most people don't adjust this particular default, and really, you shouldn't adjust it either. The 30 second time-out is a good compromise setting between allowing a couple of delays on a sluggish network vs. not waiting too long for a dead network. If you have exactly 30 seconds of delay, something on your machine wants to go elsewhere.

 

[RodShinall]

Thank you for your reply. The delay is in the range of 8 to 12 seconds but never as long as 30 seconds and occurs only when Access is running.

 

[Isaac]

@RodShinall
As it would be interesting to continue isolating this problem, I think, here is another idea to get Access out of the picture, and if performance here is better than maybe this does point back to Access.
Try your same method using a vbscript file that just contains:

set sh=CreateObject("WScript.Shell")
sh.run """C:\Program Files\SumatraPDF\SumatraPDF.exe"" ""D:\Periodical Reference Index\123.pdf""", 1

Just change 123 to a valid Record ID.

 

[The_Doc_Man]

Thank you for your reply. The delay is in the range of 8 to 12 seconds but never as long as 30 seconds and occurs only when Access is running.

OK, not a network timeout. Doesn't mean that it isn't network related but not my first guess. Also, if it is not a timeout, there will probably not be an entry in the Event Logs.

 

[RodShinall]

@RodShinall
As it would be interesting to continue isolating this problem, I think, here is another idea to get Access out of the picture, and if performance here is better than maybe this does point back to Access.
Try your same method using a vbscript file that just contains:

set sh=CreateObject("WScript.Shell")
sh.run """C:\Program Files\SumatraPDF\SumatraPDF.exe"" ""D:\Periodical Reference Index\123.pdf""", 1

Just change 123 to a valid Record ID.

Thank you for your reply.
I tried your code but unfortunately the result is the same. I get a not responding message with a delay of about 10-12 seconds.

 

[Gasman]

In the interests of debugging, I'd be trying another pdf program?. Foxit perhaps?

 

[Isaac]

Thank you for your reply.
I tried your code but unfortunately the result is the same. I get a not responding message with a delay of about 10-12 seconds.

Ahh. Well that's an interesting and meaningful result. I mean, it's unfortunate that it's still slow, but at least you know it may not have much to do with Access.
On some corporate PC's I've had that are saturated with group policies and AV type of stuff, my vbscripts take about an extra 3-4 seconds just to initiate, it seems...but your delay does seem worse. : (

 

[RodShinall]

I finally discovered the solution to my problem. When connecting to my network I must check the Connect Automatically box. When I do this there is no delay in displaying PDF's.
Thanks to all who replied.

 

[Isaac]

Glad to hear it's working!

 

[The_Doc_Man]

Makes sense. "Connect Automatically" means you "hide" the connection delay behind other actions that can occur in parallel because the network connection is based on a device driver and network service task, each of which has its own separate thread. But by not connecting early, you connect when you need it and then need to wait for all the handshaking that goes on to establish whatever links are needed. In effect, you linearize the connection process by delaying it.