Thnx for the feedback on your experience. I agree it would actually help us all including MS, to have a documentable sequence - which is unfortunately the only way to resolve the problem. My focus has not been upon the mechanics of the problem but maybe if it happens much more often I'll get to see a pattern.

Meanwhile, back in the form designer, maybe you can answer another question otherwise I'll throw it out to all: Do you know why a simple form consisting of just 2 combo list boxes with only a few hard-coded choices (i.e. no cursor feeds) and & 1 spinner and a "go" and "cancel" button, both in a common command group, should work perfectly as an frx (the "go" click calls a regular SQL syntax coded program depending upon the choices made from each of the 2 combo lists) but will not work as either an app nor an exe?

This whole project is assembled using the project manager and is very convetional and very basic. When compiled inot either exe or app the form fails to find a couople of declared public variables amongst other issues but this is never a problem with the stand-alone frx module. The mystery deepens by the moment. Best wishes, and Thnx regardless of if you have an answer or not. ./psb.

>Patricia,
>
>When it happens to me I'm usually in and out of the class/form designer and having the debugger popup while doing development. Most of the time it happens to me with .prg files that are stored in the .. directory, ie one level up from the project directory.
>
>If you can ever isolate a specific sequence of events that'll cause it to happen MS would love to get them so this bug can be fixed, but it requires a reproduceable sequence for them to duplicate it.
>
>>Like you say, shutting down VFP & restarting is the only way that I have found around this problem so far which thus sounds very much like a subteranean (is that how it's spelt?) bug :)
>>
>>I have wondered if this problem is a factor arising from a certain combination of events such as of canceling program operation will using the debug tools; i.e. perhaps some part of the debugging mechanism puts a file lock on the program fxp file (though I cannot imagine why it would so do) and then fails to release under certain conditions - but this is pure speculation based only upon the apparent propensity of this problem to appear only after invoking debug and using it for a succession of trial runs whereas it does not seem to occur under none-debug mode conditions. It certainly has nothing to do with any of the conditions attributed to error 102 since - as admin - I have all the necessary file permissions, etc & hence error 102 is really erroneous in this case.
>>
>>Who knows, maybe someone else out in UT land has an explanation but at least we have agreed upon the sledgehammer resolution - close and restart!!! ;~( Unfortunately, no way around the frustration nor the waste of time; yuk. Thnx.