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 [profoxtech-boun...@leafe.com] on behalf of Desmond Lloyd [desmond.ll...@gmail.com] Sent: Sunday, September 28, 2014 11:07 AM To: profoxt...@leafe.com 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: ProFox@leafe.com 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/7d9e7f72b813014c8fd022cf04f820ed0137360...@ex06.drdad.thenewarkarena.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.
