Hi Jim,

Thanks for the reply. We have considered that issue as a possible cause. In this case, the changes are being lost to a record that already exists, ie. we aren't appending records. Do you think this MSKB entry still applies?

We may try making a copy of the table using VFP's COPY TO. Thanks for the suggestion.

>Joel,
>
>This has some of the same characteristics as MSKB #Q293638.
>To date, to my knowledge, the problem has not been successfully isolated BUT VFP8 has implemented a 'trap' that emits an error (#2095 I think) under the specific instance that a table header's record count (used to calculate the file size) does not match the physical size of the table).
>
>Maybe you could check for that condition yourself in your code and also use that as a basis to advise the user. The calculation is simple enough:
>HEADER("TableAlias") + (RECCOUNT("TableAlias") * RECSIZE("TableAlias")) + 1
>
>... and the physical size is obtained by opening the table using LLFF and then the instruction:
>PhysicalSize = FSEEK(nHandle, 0, 2)
>where nHandle is the handle returned by FOPEN.
>
>good luck. This has proven to be a tough one for people that get it.
>
>Note, too, that PACK will actually leave the table/CDX UNTOUCHED if there are no deleted records in the table. Since a bad disk area cannot be easily excluded from cause you may want to use a copy operation instead and posibly also leave the original table intact in place (to prevent re-occupation of its space).
>
>