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/CAAJXvaNtPV8zrTbFWakVj5Ofa+O=qvq6jbtvshwene_afsq...@mail.gmail.com ** 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.
