>>>>>I have a VFP9 app that runs against Sql Server. When I runs the forms from the FoxPro IDE, running against the same Sql Server database which is located on a central server down the hall (i.e. NOT on my local developer machine), all the forms load up and run very quickly.
>>>>>
>>>>>However, once compiled into an exe, and runnging the compiled exe from by same devloper box (outside of the FoxPro IDE), the forms take about twice as long to load up. This is very consistent across all forms.
>>>>>
>>>>>Is there particular reason that forms would run more quickly inside the FoxPro IDE than when compiled into an EXE?
>>>>
>>>>I FIGURED IT OUT!!!
>>>>
>>>>Remedy here: http://mattslay.com/foxpro-newobject-fast-here-slow-there/
>>>
>>>Just a swag... are you using SYS(2450,1) to indicate that resources should be searched within the executable first?
>>>
>>>Walter,
>>
>>
>>Walter,
>>
>>This is very interesting indeed.
>>
>>Please explain me if I frist do a 'set procedure to' for each and every procedure file, is it than advisable to also apply sys(2450,1) in case you want to search within the appliction first? And if so, do I have to apply this sys(2450,1) only once, e.g. in mySettings.prg or do you have to apply it again and again before you call a procedure for which you implicitly would like to search within the application first?
>>
>>Regards,
>>Koen
>
>I've got a sys(2450,1) at the start of my application so that a SET PROCEDURE will first look for the PRG file in the executable. It only needs to be set once. If not doing that it will first search on disk along the SET PATH which can be slow. Since the NEWOBJECT() allows for a parameter indicating the PRG, my guess is that the slowness could be due to the very same mechanism. I haven't tried it myself but its worth to figure out.
>
>Walter,

a sore point is the absence of a setting to prevent the search
with set path.
The idea of trying somewhere, until you find something
It is not programming