Update of the description of the problem, as per status [08/24/2002] :

Initiated by some happening at day 1 at the last append of a new record for a table, something overnight causes the table to get corrupted at the first write of a new record to that table at day 2. This always occurs at the overflow of the last block from the table to a new block.

A browse (no Index) with Set Refresh To 1,1 will show the last records of the table continueously changing from nulls to the original contents by sitting back and looking at it.

When nobody writes to the portion of the data corrupted as the browse shows, eventually the table will come in a state that all becomes fixed (no changeing from nulls to original data anymore). This will show the very last record from a block to be corrupted, the remainder of that record being alright in the next block.

During the time the situation is not "fixed" yet, the complete block where the corrupted record as mentioned before is in, shows corrupted.

Opposed to earlier findings, it now turned out that the physical file just contains the proper data, but for the portion of the last record in that block, really containing nulls.

It can fairly be said that the last record is corrupted, only because it was written to in the situation the block showed corrupted to the VFP PC using the block. Hence, it has been proven right now, that during the stage of the block showing corrupted (while this is not the case at all), will fix the written record to be corrupted (nulls).

The problem was very hard to analyze so far, now knowing that each field written by a PC at which the block shows corrupted, will
a. write the normal contents of the field to the approprate area within the block and
b. will fix the remainder of that record only within the block with nulls.

From all now can be derived that the ever completely corrupted area from the portion of the last record in the "corrupted" block, is due to an append blank causing this portion to be fixed with nulls. Also can be said that right after that, the VFP instance can't find the record (block !) anymore to apply the "replace" data in that block.

The physical block in the file is okay, but something shows it to VFP as nulls. Re-fetching the block will show the data okay as long as the block has not been written to from an instance who received the null data.
Update of the description of the problem, as per status [08/23/2002] :

Initiated by some happening at day 1 at the last append of a new record for a table, something overnight causes the table to get corrupted at the first write of a new record to that table at day 2. This always occurs at the overflow of the last block from the table to a new block.

A browse (no Index) with Set Refresh To 1,1 will show the last records of the table continueously changing from nulls to the original contents by sitting back and looking at it.

When nobody writes to the portion of the data corrupted as the browse shows, eventually the table will come in a state that all becomes fixed (no changeing from nulls to original data anymore). This will show the very last record from a block to be corrupted, the remainder of that record being alright in the next block.

During the time the situation is not "fixed" yet, the complete block where the corrupted record as mentioned before is in, shows corrupted.

Opposed to earlier findings, it now turned out that the physical file just contains the proper data, but for the portion of the last record in that block, really containing nulls.

It can fairly be said that the last record is corrupted, only because it was written to in the situation the block showed corrupted to the VFP PC using the block. Hence, it has been proven right now, that during the stage of the block showing corrupted (while this is not the case at all), will fix the written record to be corrupted (nulls).

The problem was very hard to analyze so far, now knowing that each field written by a PC at which the block shows corrupted, will
a. write the normal contents of the field to the approprate area within the block and
b. will fix the remainder of that record only within the block with nulls.

From all now can be derived that the ever completely corrupted area from the portion of the last record in the "corrupted" block, is due to an append blank causing this portion to be fixed with nulls. Also can be said that right after that, the VFP instance can't find the record (block !) anymore to apply the "replace" data in that block.

The physical block in the file is okay, but something shows it to VFP as nulls. Re-fetching the block will show the data okay as long as the block has not been written to from an instance who received the null data.
Update of the description of the problem, as per status [08/23/2002] :

Initiated by some happening at day 1 at the last append of a new record for a table, something overnight causes the table to get corrupted at the first write of a new record to that table at day 2. This always occurs at the overflow of the last block from the table to a new block.

A browse (no Index) with Set Refresh To 1,1 will show the last records of the table continueously changing from nulls to the original contents by sitting back and looking at it.

When nobody writes to the portion of the data corrupted as the browse shows, eventually the table will come in a state that all becomes fixed (no changeing from nulls to original data anymore). This will show the very last record from a block to be corrupted, the remainder of that record being alright in the next block.

During the time the situation is not "fixed" yet, the complete block where the corrupted record as mentioned before is in, shows corrupted.

Opposed to earlier findings, it now turned out that the physical file just contains the proper data, but for the portion of the last record in that block, really containing nulls.

It can fairly be said that the last record is corrupted, only because it was written to in the situation the block showed corrupted to the VFP PC using the block. Hence, it has been proven right now, that during the stage of the block showing corrupted (while this is not the case at all), will fix the written record to be corrupted (nulls).

The problem was very hard to analyze so far, now knowing that each field written by a PC at which the block shows corrupted, will
a. write the normal contents of the field to the approprate area within the block and
b. will fix the remainder of that record only within the block with nulls.

From all now can be derived that the ever completely corrupted area from the portion of the last record in the "corrupted" block, is due to an append blank causing this portion to be fixed with nulls. Also can be said that right after that, the VFP instance can't find the record (block !) anymore to apply the "replace" data in that block.


The physical block in the file is okay, but something shows it to VFP as nulls. Re-fetching the block will show the data okay as long as the block has not been written to from an instance who received the null data.