>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?

It's hard to say. On the surface, no. But on the other hand we have heard of very few reports here on UT and MS surely has more and theirs **may** include your conditions. Can't hurt to manually check out the physical/logical sizes. It may be, for instance, a specific problem in END TRANSACTION processing and that the 'off by one' record count condition is one way to reliaby reproduce the problem but that other conditions may also apply. For instance, there has been no indication that an 'off-by-one' conditions impacts in any way a non-transactional write or update.

Certainly it is the case that missing records are easier to spot than UNupdated records.

IF you do get to the bottom of it, PLEASE make sure you discuss it here. This will effectively also let MS know, though you could also advise them directly too.

good luck

>
>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).
>>
>>