I think most of us have experienced the same, and I guess is the first step in data corruption (data is "mostly" OK), though I'm not an expert in these issues.
To fix it I just do:

replace myMemoField with myMemoField

and 95% of the times the problem is gone (this way you can avoid the extra steps of copying to a new table, blanking and copying back).

And why you can access the memo fields and can't pack it? My guess is that you access the memo fields because FoxPro goes to the exact location to retrieve whatever is there, no matter the contents, and when packing it scans the whole memo file, it's surprised by illegal characters-entries and crashes. That's only my guess, as I told you I'm far from being an expert.

Javier.

>Hello All,
>
>I have a production server that was recently affected by a virus. The server crashed and the system folks got it going again.
>
>About three weeks later I needed to design and new report in one of the applications that runs on the server. The data is obviously on the server as well.
>
>I copied the database to my local hard drive to work on the report. Every time I tricd to run a query against one of the tables I got a C0000005 error and VFP would of course terminate.
>
>It took me a while to realize that the problem was the data, not the new report, sql statement or form in the application.
>
>Now here is the odd thing. I can still access the form that manages that table just fine. I can read, edit and delete records from the table with no problems at all. The table has one memo field.
>
>I can open the database and then the table and browse it just fine. However, when I attempted to pack the table, I received an error indicating that the memo is missing or invalid. So we obviously have a corrutption problem with the fpt file.
>
>Upon browsing and looking at some of the data in the memo field, I did encounter garbage characters. So here is what I did to fix the problem. I created a small utility program that opend the database and table. I then created a free table that contained two fields: one to hold the primary key and one to hold the memo data.
>
>I then scanned the table for !EMPTY(the_memo_field) and wrote the primary key and the contents of the memo field to the free table. Then I replaced all of the existing memo fields with and empty string. I was then able to pack the table without any problem. I then read the temporary table and updated the original table with the memo data from the free table.
>
>Well to my suprise that corrected the problem with the table. The only thing the users had to do is now go the the records where the garbage was and delete those characters via the editbox. I had previously determined that six records had junk in the memo field.
>
>Can anyone tell me why this corrected the problem? Why were the users still able to read and write to the table using the application without errors?
>
>If it were not for the new report, I would neve have know we had a problem with the database.
>
>Thanks for any insight or comments.
>
>Pat Moran