Slower performance if application launched by SHELL command

[Trevil]

We are testing a new release of an application developed with Access-2000, but find a very severe performance problem when the application is launched by a VB6 program that issues a SHELL command.

When launching the application by double-clicking in Windows Explorer, one screen will load in 2 seconds and will receive about 270KB of data (based on DUMeter).

If we launch the program via our VB6 program that uses the following code:
lvstr_AppID = Shell(gvstr_LocalPath, 1)
the same screen takes 23 seconds to load AND will receive over 40MB (yes, MB) of data. The value of LocalPath = C:\PROGRA~1\MICROS~2\Office\MSACCESS.EXE "C:\Program Files\FORPost\FORPost.mde"

I have confirmed that the same FORPost.mde is being used in both scenarios.
The workstation is running Win-XP and Office XP; we tried converting the database format from 2000 to 2002, but that made no difference.
The prior version of the application was created in the same fashion about two weeks ago, but it does not have this performance problem.

Does anyone know why the two different launch methods would produce such different results?

The backend database and the tables inside the MDE are the same; since it's an MDE, certainly the code can't be changing; there is no code that does anything based on how the application was launched.

I thought that I had seen enough strange things in my career, but this ranks in the top 5! Any and all suggestions are very welcome!




Learn from the mistakes of others. You won't live long enough to make all of them yourself.

 

[lameid]

2 things to try...

1) Accept that the MDE is weird for some reason and make a new one.

2) If it was Access code, I would create a hyperlink and follow it to open the MDE when shell did not play nice.

I assume of course that the Office XP installation is fully patched.

As for why... I'm not even going to try and guess.

This makes your top 5 weirdest things? I'm envious.

 

[MajP]

LameID,
I have no idea about this issues, but I think I can break into the top 5 weirdest things categories. See thread705-1114647

 

[Trevil]

Thank you very much for your input.

1. Yes, we created several different MDE's -- using different workstations in different environments. Normally we use a VB6 application that does
"acApp.SysCmd 603, strDBPath, strMDEPath"
but we also created an MDE by just doings "Tools | Database Utilities | Make MDE File"

2. We could look into the hyperlink idea, but I think there is something happening at either the OS level or Office level that is creating the problem.

As for the Office system being fully patched, it has SP3 installed, but we noticed an older revision between that workstation (which is hooked to a server in our test lab)and what is found on our "production" workstations (10.6771.6830 SP3). I have asked someone to repeat the test using a different server.

Oh, once this gets resolved it will come off of my weird list!

Thanks again!

Learn from the mistakes of others. You won't live long enough to make all of them yourself.