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-9ff28c3a8...@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.
