>.
>>
>>The only thing I know I did to this table was an Alter table to add a new field. I can't remember whether I had the original DBC open or not when I did that. Could this have caused my problem? If not, does this sound like a problem with the table or the DBC and does anyone have any recommendations on how to resolve?
>
>
>ALTER TABLE rebuilds the table header and the table header contains field information and a pointer back to the database
>The DBC also stores field information
>so you should keep the database open when doing an alter table but VFP should take care of all this overhead for you without causing any errors.
>
>there is no path info because the database AND tables are in the EXACT SAME directory , correct?

Yes, they are. I guess I misunderstood. It sounds like you're saying you only see this if the tables and DBC are in different directories (I've always kept these together).

>but there should atleast be a ".dbf" filename inside the "property" field of the DBC. In effect, that ".dbf" IS the path info because it is the path FROM the DBC to the TABLE.

Nope, as I mentioned all I say was the trigger references, e.g. ri_update_blah
>
>Exactly when did you issue an ALTER TABLE command?

I did this yesterday and I can't remember whether I had the DBC open or not when I did. I believe I did, but wouldn't swear to it. That's why I was wondering if doing this the wrong way (although it did correctly alter the table itself) could have caused the problem. One other thing just popped into mind. You mentioned using "free" table. I didn't use that command, but something like "Remove". In reading the help, it sounded like I didn't want to use the free table command (but I can't remember why). But it does sound like something screwy was written to the header.