>>>I think it's safe to rule out access latency caused by AV software. Reason I say that is I can get to just before the COPY TO is issues and wait for as long as I want (i.e., let AV do its thing), then let the COPY TO run and I will get Error 20 the first time.
>
>VFP's autospanning to disc can be part of it: it's not always predictable if/when VFP autospans cursors or intermediate results to disk, at which point the virus scanner takes an interest. Is COPY TO more likely to create temporary disk files to provoke the glitch? Maybe watch the temp folder to see whether new tmp or index files appear.
>
> If you're using the default %TEMP% environment variable for VFP's TEMP setting, that's a popular vector for email/website hacker payloads, so very likely to be scanned on customer PCs. So the other suggestion again involves VFPA that lets you change your TEMP setting at runtime. Move VFP's working files somewhere outside %TEMP% to a location that's only used by your app, so no need to virus scan. You could also do this in a local config.fpw, but that's an extreme security risk as it allows hackers to inject their own code with a text editor.

Hi John, and thanks for the info.

I feel if it were this type of issue it would not consistently fail at the same point each time (literally the same row). That's just a "feeling" on my part--not a known fact.

We're hammered right now with requests so unfortunately [?] since I got the code working I need to move one, but would be interesting to try what you suggest, as well as do another deep dive into the incoming data (lots of imports are processed by this same code without problems... again a "feel" of mine is this is data related), collate sequences, AV, etc.

Thanks again. Much appreciated!