I know there's no magic. What I mean is that one minute I'm editing a project then I close it. The next minute I try to open it
again and it's corrupted. If the computer or vfp or some other program crashed during that time I could accept it. I'm sure something
affected it but I have no idea what. From reading posts here I see that others have experienced the same thing. That is what I
mean by "no good reason", notice I didn't say "no reason".

>>That's exactly what I'm getting at. I can't think of anything more safe than an ascii file while I have had form and project files become corrupt.
>>For no good reason too.
>
>Joe,
>
>There is always a "good reason". If you know what it is you can prevent the damage in the first place. Just because we don't know what the "good reason" is does not mean there isn't one. Unlike popular belief there is no magic that happens in a computer.
>
>Memo fields are no more or less vulnerable to curruption than any other disk files. There are measures that can be taken to reduce the vulnerability of any file to damage. These measures are invariably in directly conflict with performance considerations, so file protection can be a trade off with performance.
>
>With memo fields the problem is not with the frequency of damage but rather the extent that the damage can affect the memo fields. Since the FPT file is using pointers to data that string along, any corruption in them can render many records to lose track of their memos. A dbf, OTOH, is more likely to have only one record affected.
>
>If your ASCII files are critical, then backup, backup, backup. Store them in the memo field but also leave them as files on disk. Use a field to store the path and file name as well as putting the contents in the memo. That way if the memo does get damaged you can reconstruct the data easily.