Aleksey,

Once again, thank you for yet more valuable information.

While I understand what you are saying, the underlying factor seems to be that .FPT files are handled significantly differently. I don't want/need to debate this - I'm sure these decisions were based on solid reasoning.

As regards increased performance hit with this approach, I think it is quite clear. When a DBF has a field updated there is no need to update the header whereas every update to a memo field requires such regardless. Of course the impact is dependent on the application and how much such updating is performed. But obviously just the head movement alone, from writing the updated block, then back to the header, then back to write another updated block etc. adds up.

Regarding the possibility that this technique may add to the instances of 'memo field is corrupt or invalid'... I'd say that this extra updating of the header AND possible multiple new blocks added, all involving pointers in the DBF itself, demands ultra-tight programming within the mechanism for all possible combinations. Add to this that hardware can return 'complete' when not (in HD cache but not yet physically written) and Windows' intervening mechanism (redirector, opportunistic locking, etc) and I simply see more complexity for FPTs than for other file types.

Anyway, I do appreciate the information you continue to provide here on these matters.

cheers

>Hi Jim,
>
>> The question has already been asked as to why.
>>
>
>At least one reason that comes to mind is a record versioning:
>
>1) When buffering is in effect, new (updated) value of a MEMO field is stored in the same .FPT file, TABLEUPDATE doesn't have to copy MEMO values, which is a good thing for performance. The original value shouldn't be overwritten to support TABLEREVERT. Also, it shouldn't be overwritten to support OLDVAL function because, although VFP caches old state of a buffered record, it doesn't cache MEMO values, which may be very expensive, it caches MEMO "pointers" instead.
>
>2) When table is shared, some other clients can have the record buffered. Overwriting MEMO value would break their OLDVAL story.
>
>3) Even when no buffering is involved, other clients can still have the record cached in the file cache, but the MEMO value may be not cached yet. If MEMO value were overwritten, those clients would "see" non-MEMO values from one version of the record and MEMO values from a different version of the record.
>
>There can be some other reasons.
>
>> I do want to note that this, of course, slows things down very much.
>>
>
>How much is this very much? Is it 70%, 50% or 5%? VFP still have to write the MEMO value to disk. It writes 8 more bytes into the header. This does take time, but it might save time for other operations.
>
>
>>I'd say it might also be a contributor to 'memo file corrupted' that seems to show up more frequently than other corruptions.
>>
>
>Could you share more details about this theory.
>
>Thanks,
>Aleksey.
>
SNIP