Messages
Reply
Edit
Delete03:28 pm
3S30X5RBM
| From: | Doug Dodge |
| To: | Doug Dodge |
Hi MB,
As Rick suggested this is an issue of the way Foxpro manages the memo file. Any change precipitates a new entry and an internal redirect in the header to the new location inside of the memo field where the old (and same as you suggested) now resides.
Here are three specific approaches.
1. Upsize to SQL if possible
2. Put up away page
Start VFP
use TheFile EXCLUSIVE
COPY TO TempFileName with production
CLOSE ALL
RENAME [orignnal table name] to Some other temp name (same for FPT file)
RENAME TempFileName to [original table name] (same for FPT file)
restart system
take down away page (or use Rick's built-in stuff)
3. Put up away page
USE [original table name]
PACK MEMO
PACK
CLOSE ALL
restart system
take down away page (or use Rick's built-in stuff)
Of the three I'd recommend #1 every time if at all possible. It's the best long-term approach. The next choice would probably be #2 as it's quicker to copy the actual file versus waiting for VFP to PACK a large file ( typically - YMMV depending on hardware etc) When VFP copies a memo file it doesn't copy the now-unused portions.
Regards,
Doug
After almost 25 years of dbf coding I am pretty surprised I am posting this question, but here goes. Why is the fpt of system dbf growing to 2g very 4-5 days? We do not store images in any of the fields, just text. The number of records is not changing. After packing the table the dbc cdx and fpt might be all of 9meg. Then a few days goes by, app crashes and reason is the table is 2gig.
Any ideas?
ps: the app is a west wind app we created.
