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?



>>George,
>>
>>Of course it's a bug. This is the venerable xBase COPY, not an OS command.
>
>Yeah it is on OS call. However, I misunderstood the nature of the problem. I'd say that this is something that VFP should correctly report. I'd recommend that you fill out a bug report on the MS site.
>
>>The bug does not happen if you open table MyTable in VFP session 1, then try to write another table onto it in VFP session 2. This is caught, as it should be. It is only when the table is open within the same session that the error is not caught.
>>
>>And if it were a system error, surely I can expect fox to report system errors to me?
>
>Nope, you can't necessarily. For example, a printer error won't be returned. In some instances, system errors such as this can, and should be caught. However, in those cases where Windows has a mechanism for reporting the error to the user, such as printing errors, you probably won't get an error message.