The copy to could in theory clean up the bad memo pointers because VFP will write all new pointers but it does not mean you got all the recoverable data.
-- rk -----Original Message----- From: ProfoxTech [mailto:[email protected]] On Behalf Of Desmond Lloyd Sent: Monday, September 29, 2014 2:46 PM To: [email protected] Subject: Re: VFP6 Severe memo bloat Thank you Dan, Actually I acquired Abri, did a test on an older version and it found beaucoup problems with the memo field(s). I did a copy to on the production file and it found nothing? Could the "copy to" have resolved the issue? (gotta be a stretch) You are the second person to recommend VFP9, and you are exactly right. I keep experiencing weird little quirks with VFP6, like code that process one way, but when you step through it it does something else. (really, no joke). After working with the forms designer in VFP9, working with the VFP6 is tough! Regards, Desmond On 29 September 2014 13:37, Dan Covill <[email protected]> wrote: > Hi, Desmond > Sounds to me like the links in the DBF have lost their way.Do the > users see the existing memo, and just can't update it, or are the > memos missing and/or scrambled? I guess I'm asking if you did a > repair operation on the DBF/FPT or just replaced the FPT file. > Anyway, if the links in the memo field don't point to the right place > in the FPT you are well and truly hosed. > Best thing might be to get a repair program (I know nothing about > Abri, but the one from Canada (Doug ??) is very good), put the > original (bad) FPT file back, and see what you can do. > Also, I don't see where the problems would be in upgrading to VFP9, > but that's another topic. > Dan CovillSan Diego > > > Date: Mon, 29 Sep 2014 11:30:29 -0500 > > Subject: Re: VFP6 Severe memo bloat > > From: [email protected] > > To: [email protected] > > > > Further problems... Now users are reporting that there updates are > > not being saved, it's just a replace mymemo with m.mymemo????? > > > > Yikes, > > Regards, > > Desmond > > > > > > On 29 September 2014 11:23, Desmond Lloyd <[email protected]> > wrote: > > > > > No general fields. I think the damage occurred when I issued a > > > Pack Memo, however I didn't run that until after I had > > > encountered the > first > > > error. (failure to run a report). > > > Do you think I would be wise I changing the block size? Sounds > > > like > it. > > > I've got about 100 users accessing these memo fields (they're are > > > nine > in > > > the file) > > > > > > Regards, > > > Desmond > > > > > > > > > On 29 September 2014 10:25, Jack Skelley > > > <[email protected] > > > > > wrote: > > > > > >> Desmond: > > >> Are there any general fields in this table? > > >> I have seen issues when a general field is stored in a table the > > >> blot > can > > >> be incredible. As you know the general field is stored in the FPT. > > >> I do store JPGs in general fields to be distributed in the system > > >> then when received the JPGs are extracted and saved in a separate folder. > Then > > >> the distributed table is erased. The memo field of the receiving > table now > > >> holds the file name as to where to load the JPG from. > > >> When I left the JPG in the memo field the blot was crazy large. > > >> So I wrote procedure that would set the blocksize of the for the > > >> FPT. When > I did > > >> this the size of the FPT was dramatically reduced. > > >> I have not experienced much blot in VFP6 when a non-general field > exists. > > >> Read in the help file about 'set blocksize' for the memo field. > > >> Jack > > >> > > >> ________________________________________ > > >> From: ProfoxTech [[email protected]] on behalf of > > >> Desmond Lloyd [[email protected]] > > >> Sent: Sunday, September 28, 2014 11:07 AM > > >> To: [email protected] > > >> Subject: VFP6 Severe memo bloat > > >> > > >> Good morning, > > >> > > >> Wanted to share with everyone and solicit any thoughts... > > >> > > >> Huge, 233 field, over 200,000 record table with approximately > > >> 20 > index > > >> tags. > > >> > > >> Runs under our manufacturing system, it has been "relatively fine". > Have > > >> some issues with memo fields in the past. Was able to correct by > > >> re-writing the file, packing memo. > > >> > > >> About a month a ago started noticing some noticeable delays when > running > > >> queries against this table. Significant but they ran.... Last > > >> night > I > > >> started to run a report and it hung... No error message, > > >> nothing, > had > > >> to > > >> "force close" VFP... Tried copying the file (with production) > somewhere > > >> and that would bomb with fatal exception error. Tried different > copy > > >> to, next 100, next 500 that kind of thing. Accidentally ran > > >> into > the > > >> fact that if I set a filter or ran a query for a certain > > >> condition it would "would blow". So I opened the culprit file, > > >> set a filter to > that > > >> condition, made a copy of the structure and walked the filtered > original > > >> scatter memvar appended blank to the copy and when it blew up I > > >> know > what > > >> record was having the issue... > > >> > > >> ...so, it turns out that some of the records had memo fields > > >> that > were > > >> stuffed (in one case) with 125,000 characters! This was after a pack > > >> memo. Replacing the contents of the malcontent memo field > > >> resolved > the > > >> issue.... I finally identified six of these puppies, made the > > >> replacement and all is well... > > >> > > >> Any suggestions, thoughts on how to avoid? Was thinking of > > >> running a query for len(mymemofield) > 5000, periodically and > > >> see what I find... > How in > > >> the blue blazes do you get 125,000 characters in a memo field? > obviously > > >> VFP6 does not like it... > > >> > > >> Appreciate the input, > > >> Regards, > > >> Desmond > > >> > > >> > > >> --- StripMime Report -- processed MIME parts --- > > >> multipart/alternative > > >> text/plain (text body -- kept) > > >> text/html > > >> --- > > >> [excessive quoting removed by server] _______________________________________________ Post Messages to: [email protected] 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/DF1EEF11E586A64FB54A97F22A8BD04423C5C42C5A@ACKBWDDQH1.artfact.local ** 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.
