I'm happy to see that I might actually have started one of the longest discussion threads for the Month of February. Of course, its always exciting to see my name or one of my own Message Subject higher up in the Stats - come the end of the Month!
Well - I ended up writing some cool code yesterday to track down the records with the problem. I had the program copy out each record to a DBF file - 1 record at a time - and then attempted to store the record number of each good record copied into another DBF file. But, of course, when VFP did a Hard Crash like it would do - it would also NOT update that DBF correctly. So - instead - I would open that DBF record counter - after each successful record copy - and update the number - then close the file. Massive overhead on disk access to be sure. Of course, when dealing with a single date range of Invoices - to track down the records with the problem - it worked quite well. And, the program - I had to restart it over and over again after each crash - but, it would continue where it left over (skipping one record - the BAD one) - until it found all the Bad Rec's in the range(there were only 3 of them). My solution then was to simply go to that record - and replace the Memo field with a Blank. Needless to say - to be thorough (since, even though the problem was reported for a couple date ranges - I really had to check the WHOLE Invoice Header file records to see if there were OTHER records with the problem). As you can imagine - once I had it continue on after the original date range - then I found HOW SLOW it would be - and that it would be creating THOUSANDS of Files during the Record testing. Luckily - at like 20 min. before quitting time - I realized that a SCATTER MEMVAR MEMO command would accomplish the SAME test - and would be blazingly Fast in comparison. So - lucky for me - I had it all working - with Scatter - and scanned the WHOLE DBF file (which we had donwnloaded from our client). So - by about 30 seconds before quitting time here (6pm) - I had the list of Bad records to give my QA Tech, and he had replaced all the Memo fields with the BLANKS - and then tested the previously Crashing Reports - and, WHAM BAM - All works now! So - thanks again for all the input from the list. Sorry for this long e-mail, but, if my suggestions help anyone in the future - it will have been well worth it for me to type this up. Have a Good Weekend to you ALL! -K- -----Original Message----- From: profoxtech-boun...@leafe.com [mailto:profoxtech-boun...@leafe.com] On Behalf Of AndyD Sent: Friday, February 10, 2012 3:51 AM This is stretching the little grey cells a bit further than they want to go - but iirc it's only the record count that gets corrupted so you can check the count in the dbf and patch the fpt to match, llfs or even TextPad in Hex format will do this. The internal file formats are available somewhere- but I forget where <g> AndyD 8-)₹ On 19:59, Sytze de Boer wrote: > 1 Beware of babies and bathwater > 2 Memos can be very useful and to avoid them can be more effort than > they're worth > 3 There are some extremely good data recovery tools out there > 4 Why not look to see what caused the problem. The corruption is a > result, not a cause > > S _______________________________________________ Post Messages to: ProFox@leafe.com Subscription Maintenance: http://leafe.com/mailman/listinfo/profox OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/289ea162f5642645b5cf64d624c66a140b7ce...@us-ny-mail-002.waitex.net ** 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.
