Hi Aleksey,
You write in you answer to Jim that "VFP always allocates new area for files opened in shared mode or when buffering is in effect". Is it possible to give me/us a brief explanation to WHY you don't reuse the old space if it is big enough, at least if only one block is used?
>Hi Jim,
>
>>
>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.
>>
>
>Are you sure a new area wasn't allocated? Even if new data fit into existing allocated area, it doesn't mean that area will be reused. VFP always allocates new area for files opened in shared mode or when buffering is in effect.
>
>Thanks,
>Aleksey.
>
>
>>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?
>>
>>Thanks
>>Jim
