>>>
>>>IOW (just like Craig's suggestion to resort to threading), I'm serving the OS, or have to invent tricks to avoid the customs/tax/excise that the OS levies on the app.
>>>
>>
>>You're not "resorting" to anything. That's the correct way to do this type of thing. Long running, CPU intensive tasks aren't meant to be run on the UI thread, because, as you found out, as far as Windows is concerned it appears like your app has hung. You're not serving Windows in this case, you're serving the end user who has to deal with crappy apps that sometimes just stop - they have no idea why or even how to exit it. That's why the OS has taken on this task. If there was some "override" switch every dev. would flip it, which would render the OS mechanism of checking for hung apps ineffective.
>>
>>It's unfortunate that VFP never had any built-in mechanism to spawn a new thread or process. However, there are a few on VFPX and Rick Strahl also has a set of libraries that can do the same thing.
>>
>>Since it sounds like you're not interested in that approach, you can also try doing a DOEVENTS FORCE. But that kills performance, unfortunately. Also double-check to make sure _vfp.AutoYield is set to .T. (it should be, by default). I'd also be interested in hearing if having a form w/progress bar helps at all. I'd guess that if you're code is performing a lot of intensive queries, then it may not. If it's mostly VFP code and loops, it may. Let us know what you find.
>
>It's a conversion, which means many insert or update statements executed one at a time, and code to create those records from cursors previously pulled. The initial big SQL to get those cursors usually finishes in a few seconds, dozen at worst. It's the time it takes to write 20000 or 300000 records across the wire... and when the time to give a progress indicator, every 100 records, is sometimes longer than the polling interval, so doevents (I didn't put Force there, but may try) doesn't do much except occasionally repaint the _screen and command window - and even that works for a while and then stops.
>
>The code does go to the end, though.

20 - 300K recs across the wire in 1 statement ? If so, Talk, Odometer and similar settings are ???