>nly 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 guess "subterranean" is spelled as "underground", but then this is not my language anyway. Subterranean bug? Do you have ants, maybe?

OK, back to work.

>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)

Weird things happen when debugger works - locking a .fxp is one of them. As if the debugger spawns some extraneous outsider process which keeps it locked, and goes astray sometimes. Sometimes VFP just GPFs and keeps something locked, and I'm not sure it ever happened without the debugger. I've had cases when quit/reload didn't work on some files (not just .fxp, happened with .vcx or .scx too), I had to reboot.

As for catching patterns, I've given it up. It's just same order of magnitude as a water tap in a 500 rooms hotel, leaking five minutes a month. Go find and fix.

> 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.

Another notorious reason for this behavior is that someone's actually running the .fxp at the moment (or used to run it and got stuck, the lock may not be released until his reboot).