Fabio,
VFP works exactly as you expect with one exception. In case when overwrite happens and Inserted.memofield occupies less memo blocks that Deleted.memofield, the rest of the blocks are lost because adjusted Length of memo (memo block header 04-07) doesn't include them anymore. The bottom line, it's not a bug but the way VFP works.
>Because I have interpreted in a soft way the VFP behavior.
>However I try to explain it to you.
>
>A memo it is allotted to blocks ( or pages ), of fixed dimension = SYS(2012)
>( memo header 06-07 ).
>
>For simple example, use only One BLOCKSIZE ( see my code ).
>
>* VFP current code
>IF LEN(Deleted.memofield)>=LEN(inserted.memofield)
> * overwrite memo with inserted.memofield
>ELSE
> * move the memo's DBF pointer to end of file,
> * append the inserted.memofield ( the old block is a zombi file area )
>ENDIF
>* set Length of memo (in bytes) ( memo block header 04-07 ) to new LEN(inserted.memofield)
>ENDIF
>
>because the memo file is a file of pages = N*SYS(2012),
>i expected a best code, like this:
>
>* VFP expected correct code
>IF SYS(2012)*CEILING(LEN(Deleted.memofield)/SYS(2012))>=LEN(inserted.memofield)
> * overwrite memo with inserted.memofield
>ELSE
> * move the memo's DBF pointer to end of file,
> * append the inserted.memofield ( the old block is a zombi file area )
>ENDIF
>* set Length of memo (in bytes) ( memo block header 04-07 ) to new LEN(inserted.memofield)
>ENDIF
>
>if this coding is used, my repro program return a fixed 1.00,
>and the probability of memo bloat it becomes very more small.
>A simple example:
>- i build a cursor/table with a memo field only.
>- i known that the size of the memo string is bounded to 8000 characters.
>- then SET BLOCKSIZE TO 16 ( 8192 )
>- with current VFP you have bloat, with expected correct code you have none bloat!
--sb--
