>>>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 ???
>
>No, no, one record at a time, being pushed from a cursor (which may have come from dbfs, csv, xls, sql, access...) to SQL. And it's not too much about speed either, it's about me being blinded while it runs.

Ok, then you are in a vfp loop and the main problem of a sprinkled in doevents, doevents force, wait window or similar is the performance hit it can trigger if asked to run on every record. so tailor your function not to tally to any fixed No. of recs which might take different time lengths, but to fire the wanted effect at first occurrance after [3..12] secs since the last time the payload ran, similar to structuring the frequency of progress bar updates to the duration of tie spent and attention span of onlooker.

Even if this is tap-dancing to windows ticks...