I have a table which has a fixed structure, and does not refer to any other data-tables, functions, views or procedures in the database.

What I want to do is:

* Backup this one table in DB 1.
* Restore this one table in X different DBs, all of which have very different structures.

RESTORE DATABASE "X" FROM "SingleTableBU" IN STORE "xxx" TABLES "MyData"!
RESTORE DATABASE "Y" FROM "SingleTableBU" IN STORE "xxx" TABLES "MyData"!
RESTORE DATABASE "Z" FROM "SingleTableBU" IN STORE "xxx" TABLES "MyData"!

The issue I am worried about is that I sometimes see Elevate complain about catalog differences during a RESTORE.

I am not clear whether you would get that in this case?

I need it to be really reliable, for any set of databases, no matter how different in structure (all on the same EDB release though!) ... otherwise I would use another mechanism, like IMPORT TABLE and distribute an XML file.

Using a BU file is easier as it keeps the data private and can be encrypted etc.

Adam


I've never tried it so I have no idea - back in the early days I "suffered" from the catalog is different problem when trying to move data from the live to development databases and switched to exort / import.

Firstly I'd suggest emailing Tim direct rather than waiting for him to pop up here. Other than that experiment and see what happens.

Personally I'd probably go with the XML file with an added bit of encryption / decription which is easy enough to write a small bit of code for and works well unless you want to do the import in EDBManager in which case you need a small external program for encryption / decryption.

Roy

Thanks for the response Roy,


>>I've never tried it so I have no idea - back in the early days I "suffered" from the catalog is different problem

Yeah, me to, that is what is worrying me.

>>Other than that experiment and see what happens.

I will do, and will post back here with a confirmation of what I find out.

Adam


As a thought to start your testing just copy the table files in toto across to their new homes. That's what I tried waaaay back and found it didn't work which is why I started using export / import.

Roy Lambert

Roy

I have run "RESTORE Database X FROM Y Table Z" on 6 separate databases and all have accepted it.

In each case table Z was empty at the start ... but Table Z won't be edited in the destination systems anyway ... so I can always empty it prior to the RESTORE.

I will test a bit more, and write to Tim, but I feel hopeful it could work.