Quantcast
Channel: West Wind Message Board Messages
Viewing all articles
Browse latest Browse all 10393

Re: VFP Memo field bloat

$
0
0
Re: VFP Memo field bloat
FoxPro Programming
Re: VFP Memo field bloat
May. 9, 2013
11:06 am
3S40NTLH7Show this entire thread in new window
Gratar Image based on email address
From:MB
To:Mike McDonald
Mike that is a great tip. I will have a look. We use html style tags to read and write to the 'stores' table in our app, so we are constantly opening and closing the stores table and saving those memos. This tip should reduce some of those saves.


MB -

One thing that will help tremendously with memo bloat is to only update the memo field(s) if the content is different. Talking about the wwSession table specifically, a session record is updated on each hit (to update the LastOn and Hits fields at the very least). However, the Vars memo field value doesn't necessary change for each hit. So the Save() method in wwSession.prg is checking if the Vars data is different, and only doing GATHER .. MEMO if so; otherwise it does a GATHER without MEMO..

IFthis.oData.vars == wwSession.vars*** Session items haven't changed - don't update varsGATHERNAMEthis.oDataELSEGATHERNAMETHIS.oData MEMOENDIF

A _long_ time ago, this was doing GATHER .. MEMO always, and this change made a very big difference in how fast the wwSession.fpt file grew.

Your situation is a bit different since this doesn't involve wwSession and you say you use a lot of memo fields, but the concept still applies - only update memo fields when necessary.

- Mike McDonald
Software Design of Kentucky


The setup is IIS with com based vfp exe's using either dbf or mysql based on the config of the server or 'store'. We've created a SAAS eCommerce platform using WWWC as the engine. We run anywhere from 10-500 eStores on a Windows box. The table that is giving us trouble is the primary 'stores' table that houses all the info about each well ... store. So on the server that is having trouble there are about 300 store records. lots of memo fields in each record. We DO have a mysql version that we can upsize to but as I wrote previously sort of stinks that we have to do that. We've had this setup for 14 years now and while this is in fact our largest store table, it is still not enough to cause this much pain I would have thought.



MB,

Question: If some of your apps use MySql and others do not, does that indicate that you have been able to get Web Connect code to talk with MySql? If so then all you'd need to do is 'point' the framework to a MySql instance of the log files? You're using the Windows version of MySql, correct?

If you don't mind my asking what is the primary program you use written it? I'm a little unclear of your setup.

Maybe wwwDotNetBridge?

Anyway, I have to think you can resolve this long term. I'd sure get tired of having to flip files every few days. *s*

Regards,

Doug


Thanks Doug. We actually have a MySql version of our app but still like to use the vfp tables on some installs. We chose MySql to make it seem like we were not biased to win only stuff. Sort of wish we used MSFT Sql, but C'est la vie.

Out of curiosity are you using Rick's tools for WWWC or .net?


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.






Viewing all articles
Browse latest Browse all 10393

Trending Articles