Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

APPEND FROM causes FPT to exceed 2GB.

Status
Not open for further replies.

ralphcarter

Programmer
Aug 8, 2006
28
0
0
US
I am trying to do a restore of data where I backed records from a table into a storage table. This particular table has 6 memo fields with data. Just 15 records into the restore and my FPT is 20M in size and I have over 3000 to restore. Any ideas how to reduce the size of the FPT table. I have to be able to do the restore while others are accessing the table so I cannot get exclusive access to do a PACK MEMO command.
 
But if you need to restore it from a backup, how come users are accessing it?

You don't really have much choice in this matter. You've just got to log users off for long enough to do the PACK MEMO.

And once you've done that, you need to review the table design to ensure it won't happen again next time. For example, you could use one or more separate tables to hold the memo fields, and relate them with a one-to-many link.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro tips, advice, training, consultancy
Custom software for your business
 
Is it bad design to have more than 1 memo field in a table?
 
I have avoided using memo fields whenever possible for many years now... they always tend to get bloated and also are one of the main causes for fatal C000005 errors....

Andy Snyder
SnyAc Software Services Hyperware Inc. a division of AmTech Software
 
No, there's no problem with having several memo fields in a table.

How are you restoring the data that it's getting so bloated? The key thing is to write to each memo field within a record only once.

Tamar
 
I'm using the APPEND FROM command to append all the records that match my index.
 
Is it bad design to have more than 1 memo field in a table?

Not at all. But your problem is that you're close to the 2GB limit. That's why I suggested splitting the table. It's not a design issue.

Also, you haven't answered my main point: if you need to restore the table from a backup, how come users are accessing it?

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro tips, advice, training, consultancy
Custom software for your business
 
How large is the FPT before the import of backup records?
You use APPEND FROM .. FOR?

Be cautious on the FOR condition used. See this example with unexpected result in the second APPEND. inspect curOne to finally also find a record not matching the FOR condition.

Code:
Create Cursor curDest( nNumber I)
Create Cursor curSource( nNumber I)
Insert into curSource values (1)
Insert into curSource values (2)
Select curDest
Append From Dbf("curSource") For nNumber=2
Append From Dbf("curSource") For curSource.nNumber=2
Browse

You may import more than you thought and that causes the file to grow larger than expected.

Besides this, SET BLOCKSIZE TO 0 before importing memo data to have the minimum length result.

Bye, Olaf.
 
Another thought ...

Make another copy from the backup and delete all the unnecessary records from it then pack it.

If you are doing multi replace on a single record, it will bloat, as mentioned earlier. So if you are replacing a memo field now from the backup then it is multi replace. That is any time in the life of a record you generated more than one replace statement on a memo field, it requires pack, else it will start bloating.

If possible, prepare your file offline and then replace it.


 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top