>George,
>
>When you say an OS Call, I understand you to mean that Fox is handing the COPY operation part and parcel to the OS. This simply cannot be what you mean, because if I key in:
>
>USE MyTable
>COPY TO MyTableCopy
>
>with TALK set ON, I get a record count as I go. Is Windows reporting percentages or bytes to Fox that Fox is converting to record counts?
>
>Also, if I say COPY TO MyTableCopy FOR MyCondition = .t., how does Fox ask the OS to slice out pieces to go to the new file?
>
>Also, if the table is indexed so that the the copy is writing out in sorted order, how does Fox tell the OS to do this?
>
>Since I don't understand what you mean, can you clarify what Fox is handing to the OS here?

Sure I can, Ken. First, it's Fox reporting the progress, not Windows (well...Fox is telling Windows to report it< g >).

All file I/O (and all other I/O, for that matter) goes through the Windows API. In order for Fox to copy a table, it first has to write the header info then the individual records in the proper format. As VFP writes these records, it'll report them if talk is set to ON. The actual I/O is handled via CreateFile() and WriteFile(), and, of course, CloseHandle().

My mistake was in thinking that Windows was reporting the error rather than VFP. After testing your sample, I've found this is not the case and is, indeed, a bug. Since my previous post, I've thought of a workaround for this. Namely, use the DBF() function passing the alias to assure that you're not overwriting an existing file. I think all of us would appreciate it if you report this. If you like, I'll be happy to contact Randy Brown, just to make sure that the Fox team is aware of the problem.