>Hi David. pmfji - I have a file which does not get updated often, has only a few hundred records, but does contain a memo field which can hold a large amount of text, +/-5Mb. Just to be clear, are you saying that it might be beneficial to pad my text with chr(0) out to some maximum possible size and then to ensure that each replace always pads out to the same size? i.e. ensure that each memo field is always, for example, 6Mb in my case?

Basically, the idea is to never let it shrink; let it bloat only when its size exceeds the current max size for that one memo for that record.

It's pretty much like

replace mymemo with padr(newvalue, max(len(mymemo), len(newvalue)), chr(0))

(or chr(32) if that fits your needs better)

If new value is longer, it'd have to bloat anyway, and the padding would actually do nothing. If, however, it's shorter, padding will still keep the whole previously allocated space still allocated. The whole point of David's analysis is that VFP will bloat the new value to a new (set of) block(s) when it's sufficiently longer than the previous value so that it gets into the next block. It doesn't check whether that next block is used or not.

Now try this

CREATE TABLE bloattest (mymemo m)
APPEND BLANK
replace mymemo with replicate("X", 5e6)
USE
DIR bloattest.* to FILE bloat_test.txt


USE bloattest
replace mymemo with replicate("X", 5)
USE
DIR bloattest.* to FILE bloat_test.txt ADDITIVE 
USE bloattest
replace mymemo with replicate("X", 1e6)
USE
DIR bloattest.*  to FILE bloat_test.txt ADDITIVE 

Here's what I got:

BLOATTEST.DBF                BLOATTEST.FPT                

   5000910 bytes in 2 files.
   9056681984 bytes remaining on drive. 

BLOATTEST.DBF                BLOATTEST.FPT                

   5000910 bytes in 2 files.
    9056665600 bytes remaining on drive. 

BLOATTEST.DBF                BLOATTEST.FPT                

   6000974 bytes in 2 files.
    9055666176 bytes remaining on drive. 

Note that the second replace didn't change the length of the files, but the third one added 10000004 (1e6 Xes added, plus 4 bytes header, with no padding overhead because 1e6 % 64=0). VFP didn't care that the originally allocated blocks for this memo were 5,000,000 bytes long - it didn't store this length anywhere permanently. It stores only the last value's length, which was 5 after the second replace. Since 1,000,000>5 and the 999,995 is longer than 61 (or 57 - whatever was supposed to fit into one block), it just added new blocks at the end of the fpt file.