>Hi Aleksey,
>
>First, congratulations to all of you for getting VFP 9.0 out the door. The VFP Team has made countless people very happy indeed!
>
>Now, on to my question...
>
>Several weeks ago, in another forum, someone postulated that .FPTs did not rewrite a memo field's content if the information still fit in the existing allocated space. The person saying this also said that they used a standard of 512 for the BLOCKSIZE, seeming to be a good value in his applications.
>Many were surprised by this, and those of us who 'tested' the concept were happily surprised to see that it was true.
>
>Yesterday, a colleague who had observed unwarranted slowness in a specific application function tracked the problem down, found MSKB #330929, installed XP SP2 as it recommended, and the problem was solved.
>While diagnosing, using FileMon, it was his observation that VFP seemed to update the .FPT header area, apparently to reflect a changed file size. It was his conclusion that the .FPT file header was being upated EVEN WHEN THE REPLACE ALLOWED THE UPDATED DATA TO FIT IN THE EXISTING ALLOCATED AREA.
>
>Can you confirm this last part? If it is true then is it something that could be amended in a future revision of VFP, or is this the 'standard' way to indicate to the OS that a file's content has changed?

Jim,

Unless changed in 9, the memo field is never written back to its original position if changed, irrespective of its size. Explored that a year or so ago, doing hex dumps to check. Compared it with Codebase, which always replaces unless the entry will no longer fit. Having seen the source code in Codebase, the change only requires a few lines of code, and I am disappointed that VFP has not implemented the improvement

Geoff