Tracy,
thanks for your input. We have not used memo fields in over 10 years. The procedure we created back then uses a 2 field table, with a Key field and a 64 byte Text (chr) field. We have a rtn that takes the memo memvar used in the edit box and converts it into 64 byte Chunks that are then saved in the Fake Memo table. The key is then stored in the table the memo field would have been in. It is incredibly fast and has never failed even when servers have been unplugged.

I was asking because I was curious having not heard much about memo field problems for a while. It seems that old problems are still there and just as bad when they happen. It does seem that they don't happen as much but I can't take a chance on a customer loosing valuable customer and insurance company notes that they just put in.

John.


>Hi John,
>
>We use memo fields quite a lot because the tables have been designed in our app over a period of 10 years. The app began as an FPD26 app and is not in VFP8. We still have versions in use that go back to the original FPD26 app. Our app is used in over a thousand locations all around the country. To repair memo fields, we use foxfix and call the dll in our app in stealth mode. We also have an external utility that we ship with our app that rebuilds the tables when they become too corrupt for foxfix to repair them in stealth mode (on the fly). You might want to check it out:
>
>http://www.hieroglyphix.co.uk/foxfix.php
>
>There are quite a few messages on the UT on using it.
>
>Tracy
>
>>Over 10 years ago we did away with memo fields because of the common problem of memo file corruption. (Computer has a bad day or Power goes out, etc. and memo file is now trash.) We changed to using a separate, standard .DBF with each memo divided into 64 byte fields with a key.
>>
>>My question is this: Are memo fields now safe? I don’t hear anything on them anymore. It used to be you would go to DevCon and someone would give an entire presentation on recovering them.
>>
>>Any and all comments are welcome.
>>TIA