>I guess I forgot to mention though that there are no actual overflows or fields with larger contents. There does not appear to be any reason. I am ceating a cursor using AFIELDS() and simply transferring the data from the cursor to the parent table using SCATTER AND GATHER.
>One of the problems seemed to be the positioning of the memo field, but I fixed that by moving the memo field to the end.
>I wondered whether it was something to do with compatibility between FPW26 tables and VFP6 tables and faster pentiums affecting the array.
>Cheers
>John

I hope I can bring you some clue;

Firstly, I recall this situation with a "Data type mismatch" causing (additional ;) grey hair, because there was an OK button only, and no clue to where what why how. This was a VFP5 app running, whereas the same code in FPDos didn't give probs. Eventually we found that this was a Numeric overlow really, but some second stage process encountering the ***.** in the file and interpreting them as Char where is should ne Num (or similar). This implied that the Numeric overflow really wasn't trapped during writing to the file.
To our findings, the real problem was about VFP not being able to shift the too large integer part of the numeric to the decimal part. Please note that I am not exactly sure anymore how this occurred exactly, but it is about the "ability" to have a nnnn.nnn number shifted into nnnnn.nn when the integer part goes too large. So, VFP allowed this in the first place (in a table), but lateron interpreted this as a Data type mismatch.
This is story #1.

Story #2 is about my recent experience with a Cursor not willing to obtain the 3 decimals from a 3 decimal source, unless I explicitly defined it (create the cursor in advance explicitly or similar). Nothing helped (SET DECIMALS etc.), and to be honest, I still didn't find the real solution to it. Possibly it's just a bug (BTW this is VFP6 SP5).

Combine #1 and #2 and possibly this is your case ...
HTH,