>Bruce,
>
>thanks for the reply. The funny thing is that as soon as I added the "SET COVERAGE TO C:\CLOG.TXT" line at the start of the program and ran the prg, it ran within a second or so, just like the VFP5 environment. Very strange, esp. since the previous effect was repeatable. So, the cause is still a mystery.

Well, that's interesting. I was going to inquire about the HW and OS, but with this news I doubt that's an issue. Since the Coverage Profiler seems to be of no use here (except to speed things up), next I would try commenting out lines of code to see if that helps locate the problem. First comment all the code out and run the empty app/exe/pgm (whichever it is), then gradually uncomment lines. That's another technique that might help isolate a delay like that.

Sometimes, switching something like CD to SET DEFA TO may help, for example. Then again, there are times when adding something seemingly crazy like:

WAIT WIND "" TIME .1

will fix various stubborn problems. It's weird, but most of us that've been coding with vfp a while know that old, but still occasionally useful trick.

Also, I'm assuming you are testing on a machine without any VFP versions installed except the vfp7 client runtimes, or at least repeating the delay on more than one machine to be sure it's not a one-machine fluke. Other possibilities are things like AV delays, permission-check delays, trouble locating runtimes, the vfp debugger running, memory swaps...but I'll wager your problem is very solvable, considering the Coverage Log has already proven it can be done. Good luck!