>>>Because, my understanding is the FILE() look for the files inside the application .EXE. And if it does not find it, it means, bad things are about to happen.
>
>The exe is already loaded into memory when the error occurs. I know this because when conducting hack tests, you can defeat any walling/commercial encapsulation scheme around a VFP exe by finding the app that *has* to be unpacked into memory eventually so it can run, and shelling it out as an unprotected app.
>
>So if the fxp is in the exe, it's in memory, not disk. For interest- could there be a %temp% folder for your login at the customer experiencing the error? If so, attempting to read a file in that location may generate file read error because it's not the user's %temp% rather than "file does not exist so lets use the one in the app" seen at other customers. What's the path to the prg in project manager and check the SYS() setting mentioned earlier to give precedence to versions contained in the exe.

My test to see if file(fxp) is found is to see if the application can "reach" the share and read the executable file. I understand that it should be in the memory of the PC.
The customer PC has nothing in the %temp% that points to my name. The reason the application tries to read from the c:\user\dmitry\.... is because it is in the .EXE file. And therefore it loads into the memory. I don't know why the .EXE has my local PC name (c:\user\dmitry\...)
In the project all PRG files are in the folder \AppFolder\Programs Basically my project structures is as follows:
\AppFolder\Programs
\AppFolder\Libs (for all VCX/VCT file)
\AppFolder\Include
and so on