>>>I moved my project to a new drive. When asked if I want to make the change permanent, I said yes. Everything was found and my project ran. However, when I clicked on the table I was using, it was on the wrong drive. I deleted that table and added the one in my new directory. Now I get the message "Table 'timinput.dbf' is not marked as belonging to the 'timekeep' database. Would you like to create the back link to mark it?" Either answer generates an error. If I delete the table from the database and add it each time I go into Visual Foxpro, my form works. Unfortunately, I cannot do this step in an executible. Any suggestions?
>>>
>>>TIA
>>>Barbara
>>This has been here since Monday. Can anyone address this for me? I can't do any development on my project till I get an answer.
>>Any help would be appreciated.
>>
>>Barbara
>
>I cannot understand what is the real problem you have. Anyway you should create a table from Project Manager using 'New' button and it will be linked to Database forever.

When moving a project, VFP does not automatically move the data associated with it. I am unclear of the process that you used to advise the project of the new location of your data, but here are a few tidbits that I hope might interest you. When moving an entire database, you must remove the database from the project. Then re-add the .dbc. in the new location. The way that your project stores data location is: .pjt file stores location of .dbc. Dbc stores location of each table. Table header holds back link to .dbc. This is a lot of moving around to do if your data locations changes. I have found it easier to create a new dbc in the new project location and add the tables again back in, after removing them from the old dbc (not practical if the database contains a bunch of views and/or RI code, stored procedures, etc.) Anyway, all this does not even address the problem of hardcoded database locations in the DEs of your forms. If your locations are hardcoded, (and you would know if they weren't, because you would have had to write a procedure to get around it) then you must remove and re-add all the tables in your DE. This all gets pretty hairy if you are unclear of what objects need to know the locations of what other objects.