Cannot add this table

[k2a]

Need some help again!
I created a new table in a wrong folder and use it already in a form. Now I wanted to move that table into the correct Data folder. So i removed that table and copied it into the Data folder then tried to add the table there.

Now a message appears: Cannot add this table, it belongs to <path + database name>

How can this be fixed?

Klaus

 

[Olaf Doschke]

Remnove the table from the form DE, put the files back, rename the table from within VFP project manager), create a new table with correct name at the correct location and append the data, then drop the wrong table.

Tables can't be moved, their header contains a backlink to the DBC and the DBC also maintains the path to it's tables as meta data. You could correct these things, but they are buried in binary parts of the file maintained by VFP not editable but in a hex editor and thus the "long run" to redo the table is recommended. Before you know the details about what to change in the dbf header and DBC data you have done this.

One other "natural" way is using the FREE TABLE and ADD TABLE commands, but with FREE TABLE your DBF will lose all attributes it can only have as DBC table: long field names, primary index, and more.

Bye, Olaf.

 

[Mike Lewis]

In general, you can't move a table if it is part of a database (DBC). Or, rather, you can move it, but there are a few hoops you have to jump through.

If the table does not have long field names ( > 10 chars) or table properties (such as field captions, validation rules, format masks, etc), then the easiest way is to temporarily make it into a free table. To do so:

1. Find the table in the Project Manager or the Database Designer (which you open via [tt]MODIFY DATABASE[/tt]).

2. Click the Remove Button (in the Project Manager), or right-click and choose Delete (in the Database Designer).

3. When prompted to choose between "remove from the database" or "delete from the disk", choose the former.

4. You will see a warning about long field names, etc. Go ahead and confirm the removal.

5. The table is now a free table. You can move it to another folder.

6. Finally, add the table back to the database, using either the Project Manager or Database Designer.

If the table does have long field names or field properties, you can always use the above technique anyway, and then manually restore the field names and properties after you have added the table back to the database.

In addition, this article might be useful:

http://www.ml-consult.co.uk/foxst-47.htm

It explains the issues in some details, and suggests some methods for dealing with them.


Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[k2a]

Thanks for your many suggestions but I fear I finally messed the whole thing.

Unfortunately I named the new table mw-praxen.dbf but could use it without complains in a form and everything run fine. As I found out that the table is in the wrong folder i removed the table within VFP project manager.

Now trying to add the table back where it was a message tells me now “Object name invalid”. Changing the name to mw_praxen.dbf and try to add it tells me “Cannot add this table, it belongs to <path + database name>”.Ok, the table itself it not complicated just C-Fields but I want keep the data on it.

What do you think, total loss?
Klaus

 

[Olaf Doschke]

Putting it back where it was with its original name would already mean its back there. Header and DBC would match again and nothing complains anymore. You have removed it without telling the DBC and you didn't free it, so the DBC will "think" nothing has changed, so there is no need to add the table to the DBC after putting the file back, it is still recognized as part of it. Think of a PC you turn off, remove RAM, but put it back where it was, before you power it on again. It's even less important the DBF wasn't there, because even if you opened the DBC without the DBF in place, the DBC doesn't check its DBFs. The DBFs chack their DBC while opening.

If all else fails, set exclusive on. As there is no real defect, you can always open a DBF, ignore such warnings as "DBC not found", turn a DBF to a free DBF this way and then append the data of it to another table.

Bye, Olaf.

 

[k2a]

Finally I managed to fix the problem with your helpful ideas, many thanks.

Mike, your wonderful tip with the free table worked fine me.

Regards
Klaus

 

[ggreen61]

You can move a table that is associated to a DBC. First remove the table from the DBC and make it a free table. Then move the table to the new directory location and then re-add back to the DBC.

The only thing lost would be if you use field names that are longer than 11 characters in the table to be moved. If so, the fields will be truncated to 11 characters when removed from the DBC.

BTW -- I have a table schema editor that does this for you.

 

[Mike Lewis]

You can move a table that is associated to a DBC. First remove the table from the DBC .... The only thing lost would be if you use field names that are longer than 11 characters ....

Which is exactly what I said several posts ago, and exactly the solution that Klaus adopted.

Mike



__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

The only new info is you have a tool doing that.

It's too late, for the DBF was already in a - let's say "confused" state - but even considering the case you have a correct DBC/DBF pair and want to move a DBF of a DBC to another folder, freeing and adding the table is not a solution I would use.

You can ranem the table and move it that way, via the project manager. Not via RENAME command but via context menu item "Rename". In the follow up Rename File dialog you cannot only change the dbf file name, you can also specify a new location via relative path from the tables current position, eg move it from where it is one folder up and into another via entering ..\targefolder\tablename.dbf

It's causing the same error, but set exclusive on, pick the table from the project manager and confirm the prompt for "relocating" the table and the DBF header is mended that way. The DBC info was already updated from doing the renaming with project manager. No need to store long field names for recreation etc. when doing it this way.

Moving a file manually via file explorer will cause a twofold problem in both DBC meta data and DBF header, which isn't mended or let's say finalized as simple.

Bye, Olaf.