>You said:
>Do you know that the reference to which database table belongs is included to the header of table. This can offer the harm you have. To remove the reference use FREE TABLE command.
>
>
>So if I copy my DBC to my production directory, then it still looks back to the development directory for the DBC data?
>
>That certainly explains my problem.

The DBC holds just the table names, along with information on all the fields, indexes, permanent relations, connections and views, plus stored procedures, extended properties etc (did I forget something?). It doesn't store any paths.

In the header of each dbf belonging to the dbc, there's the name of the dbc, stored as a relative pathed filename. If they're in the same directory, it's just the dbc name with extension.

If you copy a dbf (belonging to a dbc) into another directory, and try to open it, it will look for the dbc with the same name as it has in the header. If it's there, OK. Then the dbc will check its records for the mention of that table - and report an error if anything is out of sync: a field of different size, name or type; too many or too few fields; missing or extra index etc etc.

What you probably have is a dbc which doesn't mention this table, and the table mentions the dbc - IOW, the dbc is an older version which doesn't know this table. Or it's a newer version where this table was dropped, and then copied back.

Moral of the story: if your dbc is out of sync with its tables, or vice versa, they're out of sync.