That's what I was afraid of. Thanks for your input on this.

>It's additional security in WIndows 7 and Server 2008. There are ways around it, but they reduce security and not recommended. The best option is to bring all files to the local drive.
>
>>Just ran into peculiar problem where attempt to launch a VFP-compiled EXE file results in a LOCFILE() dialog looking for the FXP file (no specific one -- so I'm guessing that it's not able to open the FXP/APP that is embedded in the EXE). Right-clicking on EXE and selecting "Run as Administrator" yields same result. If I relocate the entire program folder to a local drive results in program launching normally. My best guess is that somehow the EXE is being blocked from opening itself to read the embedded FXP/APP (basically going on assumption that EXE is merely a launcher for the runtime library along with embedded FXP/APP). Going on that assumption, I tried the following kludge:
>>* Make a copy of the EXE -- with extension changed to FXP (this is on the network share)
>>* Modify shortcut to EXE so that we add above-created FXP file as a command-line parameter
>>... and whadd'ya know. It worked!
>>For now the customer is happy as the program is running, though I'm scratching my head on exactly what settings within Windows is involved that resulted in the problem in the first place. I've a nagging suspicion that it's part of a series of security changes that had been implemented (something like the one that caused CHM files on network share to stop working right) -- and that although it's likely I can change these settings to resolve this specific problem -- it'll result in "poking holes" into security -- which would likely result in some resistance by customers. Or in the worst case would be, in implementing the said changes, we now leave ourselves open for being blamed for making their network more susceptible to virus/malware attack...