Codeunit 412 (Common Dialog Management) very slow

David_Singleton

I have a strange issue.

Basically a client is using matriksdoc. The problem is that on import file, it takes about 13 seconds to open the Common Dialog Screen.

Debugging I can track it down to the point in CU412 where is calls CommonDialogControl.ShowOpen, this code

IF Action = Action::Open THEN BEGIN
  starttime := TIME;
  CommonDialogControl.ShowOpen   ;
  endtime := TIME;
END ELSE

Shows it takes about 13 seconds to open the form. (Allowing for the user delay in double clicking on a file).

The odd thing is that we tried lots of different machines, the live environment with Win7 and XP, Nav 4 Native Nav2009 SQL my laptop, Terminal Server, running direct on the server (Win2008) and withing measurement limits it's always 13 seconds. My initial feeling was network or Active Directory or local Operating system, but in every combination we tried we had the same speed.

FYI the code is 4.00sp2 originally running on 4.00sp3 native executables now on 2009R2 SQL 2008.

jglathe

Hi,

David Singleton wrote:

The odd thing is that we tried lots of different machines, the live environment with Win7 and XP, Nav 4 Native Nav2009 SQL my laptop, Terminal Server, running direct on the server (Win2008) and withing measurement limits it's always 13 seconds. My initial feeling was network or Active Directory or local Operating system, but in every combination we tried we had the same speed.

I'd suspect that the networking setup /stack is basically the same on all machines. Is it possible that the folder tries to poll the TOC of a network drive that's not there or something like that? A sure sign would be that opening the file dialog in some other application is equally slow. Would be my guess...

with best regards

Jens

David_Singleton

jglathe wrote:

Hi,

David Singleton wrote:

The odd thing is that we tried lots of different machines, the live environment with Win7 and XP, Nav 4 Native Nav2009 SQL my laptop, Terminal Server, running direct on the server (Win2008) and withing measurement limits it's always 13 seconds. My initial feeling was network or Active Directory or local Operating system, but in every combination we tried we had the same speed.

I'd suspect that the networking setup /stack is basically the same on all machines. Is it possible that the folder tries to poll the TOC of a network drive that's not there or something like that? A sure sign would be that opening the file dialog in some other application is equally slow. Would be my guess...

with best regards

Jens

That was my first reaction, but as I said in the post it's exactly the same on my laptop with a local SQL server and no domain.

kine

In many cases it could be just because e.g. nonexistent printer is defined on some server etc. Than when OS tried to collect data about the status of this printer, it need to wait for timeout... Try to look to this direction...

David_Singleton

kine wrote:

In many cases it could be just because e.g. nonexistent printer is defined on some server etc. Than when OS tried to collect data about the status of this printer, it need to wait for timeout... Try to look to this direction...

No it can't be anything specific to the server or network, since I can reproduce the exact same response time (13 seconds) on my laptop with 2009R2 and its own local SQL server or 4.00 Native. As what we get on any one of 4 different servers at the customer site, on XP, Vista Win2008 (RDP) or Win 7.

The only thing in common is the database, so it has to be a Nav object or data.

David_Singleton

kine wrote:

... it need to wait for timeout... Try to look to this direction...

OK the timeout got me thinking. The weirdest thing was that on every environment it took the same time (about 13 seconds). Turns out the call to

FileName := CommonDlgMgt.OpenFile(I_IMPORT, FileName, 4, '*.*', 0);
was called with FileName = \\ServerName\FolderTypo\Subfolder\*

i.e. with a typo in the folder name.

So the \\ was telling the system to look on the network, and the common dialog must have a 13 second time out.