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/caajxvanq0fypz7yb5aivndvb-tzzbr0kun6gwp0pbc8pmwl...@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.
