On 11/3/2016 2:24 PM, Gene Wirchenko wrote:

[snip]

>> I'm handling one of Jeff Johnson's (RIP) clients and having this issue.

>> I was about to create a simple utility for the end-user to grab the

>> table and pack it, but curious if you've got a better idea?

One thing I put into my design is working with temporary cursors or

objects (aka from SCATTER MEMO NAME oDataRec....). I rarely have user

interface objects directly accessing DBFs.

As I recall, the main reason for memo bloat was caused when saving data.

Specifically, if I was editing a memo, then saved it, if the contents

were larger than my "blocksize", VFP would create a whole new "block" in

the .fpt file. The original block is essentially wasted space at that

point. I think there are some nuances to this: e.g. VFP doesn't see it

as "bigger" unless the "blocksize" threshold is crossed - or maybe the

text has to be "bigger" than the text 1st edited. I can't remember.

So, if you have a GUI screen element that is directly bound to the DBF

memo field, every time you type a character (well, every few characters

maybe), a new .fpt block gets assigned, wasting the previous one. So

imagine if you have users typing quite a bit of text in there, editing,

yada yada. One editing session might cause dozens of "blocks" in the

memo file to be wasted. But if you take my approach, there is only 1

"write" operation (when data is saved) and therefore, at worst, 1 wasted

.ftp "block".

Take a look at "SET BLOCKSIZE". If you can't really change a bunch of

source code, simply "recreating" a table with a different memo blocksize

can sometimes solve the bloat problem. E.g. if the memo field will

almost always have more than 100 characters, but rarely have over 512,

do a SET BLOCKSIZE to 1. Once the table is created I think the blocksize

for the memo fields are "locked in". And I don't think a simple MODIFY

STRUCTURE will adjust to the new blocksize, so you may have to do some

"table-create-swap" thing. The default is 64 bytes. And be advised,

setting it to 1 thru 32 is not in bytes, it is in 512 byte chunks (SET

BLOCKSIZE to 1 is 512, setting to 2 is 1024, ... up to 32). After 32,

the number is interpreted as straight bytes.

Of course, as always, test these things out, run some variations.

HTH,

-Charlie

[snip]

_______________________________________________

Post Messages to: ProFox@leafe.com

Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox

OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech

Searchable Archive: http://leafe.com/archives/search/profox

This message: http://leafe.com/archives/byMID/profox/036fab06-2c19-0bf0-76b5-9ff28c3a8bf6@verizon.net

** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.