Hector,

Thanks for the reply. I think the answer is to put everything in a .PRG and don't call .APPs. In this specific case the .PRG is 10x faster than the .APP. I was wishing that there was some sort of SET PROCEDURE statement or something else I could do to make the APP run faster.

It's just that I have been doing this for years with my webconnect apps. I have never experienced this kind if slow down by having my EXE call a APP. The reason I call .APPs is so that I can FTP a new .APP to the web server that contains my WC EXE, then rename the appname in a table so that the newly uploaded .APP file is run on the next hit.

Thanks,

Jerryt




>
>I am not sure how VFP/Windows handle memory space and other internals of VFP applications, but it kind of makes sense that it takes (much) longer in the .APP approach.
>
>When you use COM components for example, it is known that a COM DLL it is much faster than a COM EXE. In the former, the caller program does not need to cross boundaries when it makes call to the COM DLL (since they both run on the same memory space.) When using a COM EXE, the COM EXE runs in a separate memory space and that involves a lot of work for Windows (although it is more secure.)
>
>I imagine this same situation is happening when you use a APP versus a PRG. VFP needs to do much more work to go to the APP, find the class and use it than if the class resides on the current application running.
>
>Keep in mind that this is just what I think it is happening. I have no strong knowledge about this and I could be completely out of base here.