Hi,

I am trying this:

1. Creating a table in DatabaseA.
2. Copying the physical data of this table from DatabaseB to the
Directory of DatabaseA.

Trying to open the table results in this error:

ElevateDB Error #100 There is an error in the metadata for the table
Accounts (The internal version does not match the version in the
configuration or catalog)

What am I doing wrong?

regards Uli

Uli,

> 2. Copying the physical data of this table from DatabaseB to the
> Directory of DatabaseA.

You can't just copy files between database directories.
You can however copy the entire database to another location coping the entire
directory, but not individual files.
In EDB a database is not a collection of individual tables, like it was in
DBISAM; you must think of an EDB database as a whole.

--
Fernando Dias
[Team Elevate]

Uli


In ElevateDB Tim has built in a version tracking system to make sure that the structure of the table in the files on disk and in the catalog match up (in DBISAM the structure was held in the files on disk). As long as you haven't changed the structure of the tables you can copy the data backwards and forwards as much as you want.

If you've made some alterations and now want to get the data across there are a few ways of doing it:

1. open both databases simultaneously under the same session (in ElevateDB or in Delphi) and copy the data from one to the other using SQL or table statements.

2. Use the Export and Import facilities built into ElevateDB (not tried and not sure it will work for different structures)

3. Reverse engineer the database, cut out all the non-insert statements, open your database, paste into a script and run

4. Nearly forgot this - re-enter everything <vbg>


Roy Lambert [Team Elevate]

Fernando,

> You can't just copy files between database directories.

I know this and I am quite familiar with this stuff already. But please
note, that I created an identical table in DatabaseA and just copied the
physical files of the same table in DatabaseB. In my opinion that should
work, IOW: The table is existent in the current Catalog.

Uli

Roy,

> In ElevateDB Tim has built in a version tracking system to make sure that the structure of the table in the files on disk and in the catalog match up (in DBISAM the structure was held in the files on disk). As long as you haven't changed the structure of the tables you can copy the data backwards and forwards as much as you want.

Interesting, I didn't know about that. Actually the structure of both
tables is exactly the same ( I just Reverse Engineered that table), but
if there is a version mismatch it doesn't seem to work because of this.

Thanks Uli

Uli

>Interesting, I didn't know about that. Actually the structure of both
>tables is exactly the same ( I just Reverse Engineered that table), but
>if there is a version mismatch it doesn't seem to work because of this.

So you'd been altering TableOld and its version was now 11.4.7 (say) you reverse engineer it and use that code to create TableNew which has a version of .... wait for it .... 0

Roy Lambert [Team Elevate]

Uli,

<< But please note, that I created an identical table in DatabaseA and just
copied the physical files of the same table in DatabaseB. In my opinion that
should work, IOW: The table is existent in the current Catalog. >>

You have to remember that the table files don't have a copy of their own
structure like they did with DBISAM.  Therefore, EDB needed a quick way to
make sure that the table files were the correct files for the table that is
in the database catalog, and we accomplished this by keeping an internal
version number that is incremented every time the table is altered in any
way that would affect the table files.  This version number is stored in the
database catalog and the table files, and is compared when the table is
opened.  If it doesn't match, then you'll see an error like you did.

The operations that modify the internal version number are:

PUBLISH/UNPUBLISH
ALTER TABLE
CREATE/ALTER/DROP [TEXT] INDEX

So, if you created a table in one database, and then made 3 modifications to
it, the internal version number would be 4.  If you then created an exact
copy of the same table in a different database, its internal version number
would be 1.  If you copied the table files from one database to the other,
you would corrupt that table for the target database.

The bottom line is what Fernando said - you can't copy around table files
and assume that they will match an existing database catalog.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim


I know this issue has been discussed before, I can't remember the exact outcome but here's another suggestion. For programmer use only how about a utility that would reset the catalog and table versions to zero.

There could be a nag screen and several buttons to press but I for one would find it useful in development (although a nightmare in a live environment)

Roy Lambert

Tim,

> You have to remember that the table files don't have a copy of their own
> structure like they did with DBISAM.  Therefore, EDB needed a quick way to
> make sure that the table files were the correct files for the table that is
> in the database catalog, and we accomplished this by keeping an internal
> version number that is incremented every time the table is altered in any
> way that would affect the table files.  This version number is stored in the
> database catalog and the table files, and is compared when the table is
> opened.  If it doesn't match, then you'll see an error like you did.

I got it now. Thanks!

Regards Uli

Roy,

thank you. I got it now. I just wasn't aware of the version control.

Uli