given the programming, safety & backup practices back in the FPW times having the paths included might have been necessary to debug - all to often I had to make sure the sources were put in the right place when debugging client side.
The really slow part used to be trying to access non-existing paths, verifying a file is or is not in an existing path does not bring such a prf hit. Probably could be modified by network registry settings, but it is better to fix the root problem of false UNC/path entries.


>We are aware to don't run the EXE from the server. Bud we have to do a lot of Work to do this, because of many infrastructures have to be changed...
>Bud: these special fxp's are compiled on the server and than copied to each Workstation. The Compilation is performed only if the code changes.
>
>So we start these fxp's localy!
>And we wonder why the execution in this special case (server changes) is slow.
>If there is no way to prevent the complete path in the fxp, we have to change our compilation routine...
>
>
>>First, don't run the EXE from the server. It WILL run slower. There are loader programs here in the downloads section that will copy the EXE and other needed files from the server onto the local drive and check for server updates on launch.
>>
>>That alone should help.
>>
>>
>>The path is probably stored in the FXP because it was hard coded in there.
>>
>>>Hi @all!
>>>
>>>In our VFP Application we offer our Customers Hooks so we/they can customize some behaviors.
>>>In the end these Hooks will be .prg Files in the subdir code.
>>>They are compiled, if they are not, and executed if needed.
>>>
>>>The complete Application is stored on an FileServer in network and every user starts the EXE there.
>>>
>>>Now, one Customer changed there Server's Hardware, which resulted in new UNC Paths.
>>>
>>>Since then our APP went slow.
>>>
>>>The Customer analyzed the Network traffic and he wondered why our APP still tries to access the Old UNC Path.
>>>Than he looked in the fxp and in the end of the File there where the "old" Paths stored.
>>>He Deleted the fxp's, our APP compiled them and now everything is fast.
>>>
>>>Bud:
>>>Why is the Path stored in the fxp?
>>>Can I prevent this behavior?